| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Hanging clients |
« View previous topic :: View next topic » |
| Author |
Message
|
| bigdavem |
 Posted: Wed May 15, 2002 9:55 pm Post subject: Hanging clients |
 |
|
Acolyte
Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia
|
Our setup - v2 client running on HP 3000, connecting to v5.2 server on NT. We can't upgrade the client, no newer version is available.
We've had a problem when we get a network failure while our client app is performing a timed wait on a queue - the client app hangs, even after the network connection is restored. One of our MQ consultants suggested that this was an issue with the v2 client - apparently the timing of a wait is performed on the server, so if the network connection is lost the server has no way of telling the client that time's up, so the client sits there forever (this was addressed with heartbeat intervals in v5.x).
Our solution was to have the client app perform a wait for 0 msec, then sleep for the rest of the wait interval. In theory a wait interval of 0 should mean the server doesn't need to keep time. When the app looped to read again, it would get a 2009 and be able to reconnect or crash.
What we're finding is that this doesn't work. The client still hangs while the network is out. Stranger still, when we restore the network connection the client usually recovers after a short period of time, but sometimes it crashes with a 2009 (after the network connection has been restored. Obviously we'd like it to crash with a 2009 as soon as it first performs the get.
Any ideas or workarounds? |
|
| Back to top |
|
 |
| kolban |
| Posted: Thu May 16, 2002 4:34 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
I am really only familiar with the V5 clients. With their configuration, you can define a client connection channel which results in an entry written to the AMQCHL.TAB file which allows you to specify a client side heart-beat interval. Default is 300 seconds (5 minutes). The client will attempt to "ping" the queue manager every heartbeat and, if eventually gets no response, will know the connection is lost. If such a feature exists in the V2 clients, then you could specify a low heartbeat and you will know that the client is marooned. The only other alternative I can think off is to use the native TCP/IP sockets keep-alive mechanism to try and tickle TCP/IP into realizing that the network is down.
If you can recreate the error, leave the client alone (in its MQGET blocked state) for 30 minutes and see what it reports now (if anything). If it wakes up eventually, the next task is to get it to wake up sooner. |
|
| Back to top |
|
|
| bigdavem |
| Posted: Thu May 16, 2002 3:56 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia
|
We had another play around with it this morning, and we found that if our simulated outage was more than about 1 minute, the app failed with a 2009 almost exactly 2 minutes after the outage began. If the outage was less than 1 minute, the app would recover as if there had never been an outage.
This actually works really nicely - our app survives transient network outages but crashes on anything a bit longer lasting. I'm not sure if the MQ client was meant to work that way, but it sure is a lot better than hanging. |
|
| 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
|
|
|
|
