Kbase P149473: AppServer broker detects death of agent and spawns new agent even though the agent process still exi
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/22/2011 |
|
Status: Verified
SYMPTOM(s):
AppServer broker detects death of agent and spawns new agent even though the agent process still exists
AppServer agent disconnects from broker
AppServer broker log produces errors 8127, 8119, 8113, 8077
ServerSocketsIPC read() IOException : java.net.SocketException: Connection reset : Connection reset (8127)
ServerIPCException in getServerIPCMsg() : ServerIPC error: ubServerSocketsIPC.read() IOException: Connection reset. (8119)
Message from server : [1]+0004%Client Disconnected#01#0 (8113)
Posted EAbnormalShutdownServerEvent for PID: <PID>
Ending serverPool thread: S-0002. (8077)
AppServer server log shows that the dead agent only does a cleanup and disconnects later when the AppServer broker is shut down.
AppServer server log shows that the dead agent only deletes many objects (like temptables and buffers) when the broker shuts down.
FACT(s) (Environment):
AppServer Server log doesn't show any errors.
All Supported Operating Systems
Progress 9.1D
Progress 9.1E
OpenEdge 10.x
CAUSE:
Some programs that are being run are not deleting the objects that they created, so over time these objects cause the agent to run out of resources and fail.
FIX:
To detect whether agents are or are not deleting their objects:
In the AppServer Agent settings, change the log entry types to be the following, then stop and restart the AppServer broker:
ASPlumbing,DB.Connects,4GLTrace,DynObjects.*
Note that you should keep an eye on the size of the AppServer broker and agent log files because they may grow large.
Then, when the broker shuts down and the agent disconnects, if there are objects that have not been deleted by the program then you will see messages similar to below. Notice that the agent is having to delete a TEMP-TABLE and BUFFER from the unnamed widget pool, these should have been deleted by the application otherwise they will be left around for the next client connection:
[date/time] P-005428 T-000000 2 AS AS Broker has terminated.
[date/time] P-005428 T-000000 3 AS DYNOBJECTS Deleting pool <unnamed> ( @ 0)
[date/time] P-005428 T-000000 2 AS DYNOBJECTS Deleted TEMP-TABLE Handle:5596 ( @ 0) POOLDEL
[date/time] P-005428 T-000000 2 AS DYNOBJECTS Deleted BUFFER Handle:5597 ( @ 0) IMPLICIT
[date/time] P-005428 T-000000 3 AS DYNOBJECTS Creating pool <unnamed> ( @ 0)
[date/time] P-005428 T-000000 2 AS AS Application Server Shutdown. (5476)
What you would do in a scenario like this is search backward for the temp-table handle 5596 associated with PID 5428 (P-005428). It will then be quite easy to see what procedure those objects were created in and can then fix them. You could either use DELETE OBJECT <handle> to delete the object when you have finished with it, or you could add the CREATE WIDGET POOL at the very top of the procedure. The CREATE WIDGET POOL statement will create a named widget pool which all objects created in that procedure will go, once the procedure ends it will clean up the pool automatically. This is different to using the default unnamed widget pool, where all objects goes into the unnamed pool which is cleaned up when the session (not procedure) ends.