Author |
Message
|
leland |
Posted: Wed May 13, 2009 11:32 pm Post subject: Help! MQ reason code: 3156! Durable subscriber... |
|
|
Novice
Joined: 12 Feb 2009 Posts: 13
|
Hi,
I have a problem with the durable subscriber, can anyone help me? Thanks in advance
I was testing my application today, the application contains a durable subscriber connected to a remote mq server, and sometimes an exception throw when I was trying to create the durable subscriber. The mq reason code is 3156(MQRCCF_SUBSCRIPTION_LOCKED).
Here are the steps to reproduce the problem:
1, Create the durable subscriber.
2, Send some messages to the subscriber.
3, Disable the network while the subscriber is receiving messages....
4, Enable the network and create the durable subscriber again, exception throws.
Notes that the you should disable the network while the subscriber is receiving message, otherwise everything is fine.
 |
|
Back to top |
|
 |
leland |
Posted: Wed May 13, 2009 11:36 pm Post subject: |
|
|
Novice
Joined: 12 Feb 2009 Posts: 13
|
Any suggestion or work around will helps me a lot. Appreciate it! |
|
Back to top |
|
 |
gunter |
Posted: Thu May 14, 2009 12:32 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004 Posts: 307 Location: Germany, Frankfurt
|
Did you search the IBM-site? There was a related problem in 5.3.
Even if it's not your problem, you'll find there information about how it works.
BTW: it's the wrong forum here _________________ Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
Back to top |
|
 |
leland |
Posted: Thu May 14, 2009 1:05 am Post subject: |
|
|
Novice
Joined: 12 Feb 2009 Posts: 13
|
gunter wrote: |
Did you search the IBM-site? There was a related problem in 5.3.
Even if it's not your problem, you'll find there information about how it works.
BTW: it's the wrong forum here |
Thanks gunter.
I am using MQ6.0.2.5, the problem is still exist..
I have try to use the clean-up command to clean the useless subscriber in the mq server, but failed..
Which forum should I come to? Sorry for my mistake. |
|
Back to top |
|
 |
gunter |
Posted: Thu May 14, 2009 1:36 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004 Posts: 307 Location: Germany, Frankfurt
|
Quote: |
Which forum should I come to? Sorry for my mistake. |
Maybe, I'm wrong, but I believe this subject fits better to JMS or configuration issues.
Th broker is not really my field. I answer only because of:
Quote: |
Any suggestion ... |
Only a hint: If you disable the network, mq needs time to realize that the client is gone. You may reduce this time by setting TCP Keepalive or heartbeats(not sure if it works on client connections) _________________ Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
Back to top |
|
 |
leland |
Posted: Thu May 14, 2009 2:05 am Post subject: |
|
|
Novice
Joined: 12 Feb 2009 Posts: 13
|
You did help me, gunter  |
|
Back to top |
|
 |
leland |
Posted: Thu May 14, 2009 6:17 pm Post subject: |
|
|
Novice
Joined: 12 Feb 2009 Posts: 13
|
Problem solved
The broker needs some time to realize that the connection between subscriber and mq is disabled, and this value can be set via the following command:
amqmdain reg <qm_name> -c add -s Channels -v ClientIdle=<val_in_secs>
For example, I change the client idle time to 10 seconds, and re-connect the subscriber 12 seconds after the exception throws(mq reason code is 2009, which means the network is disabled).
 |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu May 14, 2009 6:25 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
And now every time an MQClient is busy doing some work for more than 9.9 seconds and it doesn't issue an MQ API call you told MQ to kill the connection. Have fun chasing down all the 2009 MQRCs all your MQ Clients are going to be reporting. You won't be able to tell if ClientIdle did it or the connection dropped for some other reason. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
leland |
Posted: Thu May 14, 2009 10:02 pm Post subject: |
|
|
Novice
Joined: 12 Feb 2009 Posts: 13
|
PeterPotkay wrote: |
And now every time an MQClient is busy doing some work for more than 9.9 seconds and it doesn't issue an MQ API call you told MQ to kill the connection. Have fun chasing down all the 2009 MQRCs all your MQ Clients are going to be reporting. You won't be able to tell if ClientIdle did it or the connection dropped for some other reason. |
It is true, but it wouldn't bother me too much currently since the mq session thread is only for receiving messages. In my app, once a message arrives, the subscriber just put the message into a local queue(not a mq queue), some time-consuming operation is executed on another thread. The 9.9s situation is hardly happen.
This is my understanding, any advice?  |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri May 15, 2009 1:28 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
follow the keep alive route... better experience that way.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
leland |
Posted: Mon May 18, 2009 12:37 am Post subject: |
|
|
Novice
Joined: 12 Feb 2009 Posts: 13
|
fjb_saper wrote: |
follow the keep alive route... better experience that way.  |
Thanks.
According to the mq reference, the keep alive setting only works on z/os platforms, so i need to change the keep alive setting on platform level for windows, not sure if it will affect other applications. (I need to reduce the keep alive time to 10s...)
For the hbint route, I need to set the value both on sending side and receiving side, but seems there is no interface for me to set the receiving side using XML.NET.
Keep researching...  |
|
Back to top |
|
 |
|