| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Orphaned connections |
« View previous topic :: View next topic » |
| Author |
Message
|
| bobbee |
 Posted: Thu Nov 03, 2011 2:09 am Post subject: Orphaned connections |
 |
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
Have a customer doing Client connection via WebLogic to a QMGR. The connections are increasing and eventually causes a memory issue, The are looking at the app to see where the disconnect issue is. BUT.......
Is there a way to identify the SVRCONN channels that are in this state and remove them. I am getting the response from a few wise people that this is not possible. Anyone else want to chime in.
I am having the app tem run a sanity check to see if these channels are being deconstructed via normal MQ-TCP/IP configurations. I am looking for a scripted method to remove these while they are looking for the REAL issue. A bandaid. |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Nov 03, 2011 3:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Use the MAXINSTC parameter on the SVRCONN to set a max connection limit from one client IP address - this will protect your QM and other applications.
You can list channel status in MO71 or MQ explorer. You can see the IP address.
You can stop those channels (from that IP address) using the appropriate stop channel command.
Setting keepalive to yes, in qm.ini may also help. |
|
| Back to top |
|
|
| bobbee |
| Posted: Thu Nov 03, 2011 3:52 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
did all that, in fact it was done already. I am not on site but I think the application is either hitting some issue or just reconnecting. In either case it seems it is not cleaning up the connections before reestablishing. So the IP would be the same and there are un-used connections down there along with current. Killing the channel would interrupt the processing transaction. This is a huge retail store chain. Not good, esp with up coming Black Friday.
They are looking for their issue and have Lvl II support with a PMR and have traces.
If there is a HBINT would that show up in CHSTATI or LSTMSGTI. Wondering if this would not be updated with at the HBINT time interval. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Nov 03, 2011 4:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You should be able to use DIS CONN to identify connections that might be orphaned.
You should also have the customer look at disabling the internal WMQ connection pool in the Java/JMS layer (USECONNPOOLING NO) if customer is at MQ v6 - you didn't mention the version. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Nov 05, 2011 8:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Verify tcp keepalive is set in the qm.ini file, and then that tcp keepalive is turned on at the O/S level, and at what value. If this is turned on, this will clean up truly orphaned connections - ones where there is no longer a valid socket on the client side.
But if the app just leaves a valid client channel running, but decides to no longer use it and instead opens another connection, these are not technically orphaned connections. They are just unused but otherwise valid connections. To go after these, you got a couple of options, ahead of fixing the program to stop creating them that is.
First, you could enable ClientIdle at the QM level. This will cause MQ to kill client channels that are valid but have not executed an MQ API call for the amount of time you have set ClientIdle to. It'll work, but it can cause problems for other well behaved apps who maintain an appropriate number of connections to the QM, but just happen to be dormant for a while. And it wreaks havoc with connection pools.
The other thing you can do is manually try to accomplish the same thing. List all the active client channels and look at the last message age. This is not the last MQ message, but rather the last MQ API call. If you see a suspect channel, I'm pretty sure you can kill it specifically while leaving other instances of that channel, even from the same IP address, running, although this is definitely not possible at older versions of MQ.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Nov 05, 2011 8:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
One of the ways you can clear the channels (if the client has reconnection logic) is to
| Code: |
| stop channel(mychl) mode (force) status(inactive) |
On the other hand, have them check what the reap policy is on connection pool in Weblogic. Remember to search for an article (developerworks?) that addresses the reap policy in connection with transaction management.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
