Kbase P180062: How to terminate SonicMQ Adapter threads in sending state which state did not change since many days
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
1/6/2011 |
|
Status: Unverified
GOAL:
How to terminate SonicMQ Adapter threads in sending state which state did not change since many days
GOAL:
What does it mean if SonicMQ Adapter thread remains in the SENDING state
GOAL:
How to terminate SonicMQ Adapter threads gracefully without restarting the whole SonicMQ adapter
GOAL:
How to free up resources on the SonicMQ Adapter gracefully
FACT(s) (Environment):
OpenEdge 10.x
All Supported Operating Systems
UNIX
FIX:
When a OpenEdge client connects to the SonicMQ Adapter, 2 connections are created. One is for sending messages and is synchronous. It won't utilize an agent except while sending a message. The other connection is for receiving and is asynchronous. It leaves an outstanding request on the MQ Adapter waiting for messages to be received. This will show up as SENDING in the status screen. If no messages are received, then the state should not change.
The only way to release these threads is to shut down the client that is connected to them. The client can be shut down gracefully, or killed. In either case, the threads will be released and will be put back to the AVAILABLE state. You can use the SonicMQ adapter log files to try and track down which client belongs to which thread. You can do a quick sanity check to see if everything is proper by looking at the active clients. This should be twice the number of threads that are in the SENDING state. If it is less, then we may have a problem.
In the unlikely event that the threads are hung or zombies, do the following:
1. Shut down all clients connected to the adapter
2. Check to see if the SonicMQ adapter thinks that any clients are still connected. If they are, try and track them down. They may be zombie client processes that are holding the connections open. Killing the client process will free up the resources on the adapter.
The following method was reported as an efficient way as well to identify the SENDING Unix processes to kill :
1) with lsof | grep <PID of the java adapter process> identify all TCP connections to this process
2) using this list, identify which one was the SENDING one and perform for each port : lsof | grep < port number of sending connection> --> the result of each of these commands is the PID from each of the SENDING connections
3) with ps -ef | grep <PID> check which type of OpenEdge client is connected