| Author |
Message
|
| smeunier |
 Posted: Mon Jun 04, 2007 5:38 am Post subject: 3156 Error Locked subscription |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
I have a customer who gets a 3156 error condition:
| Code: |
Durable topic subscriber failed! com.ibm.mq.jms.MQTopicSession@5bb966Broker command failed: 3156 Reason code 3156 |
This occurs when an interrubption to the message broker has occured. It appears that through various forums and documentations, that the durable subscription becomes locked by the message broker. Repeated attempts to resubscribe fail due to the same error code. No where in any of the literature, does it discuss how to resolve the situation, either from an application perspective or an administrative persepective. The only thing I have been able to do, is remove the subscriptions, which then allows the application to register a new subscription with the same client ID. However, all the messages(durable), become orphaned and cannot be retrieved by the client application. In effect, they become unreachable by the application.
Does anyone have any tips on how this could be remedied, by the application? Is there a lock file that needs to be removed? What is the solution?
We are running
AIX WebShpere MQ 6.02.0
AIX WebSphere Message Broker 6.0.0.3 |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jun 04, 2007 2:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Change your Topic definition so that it provides an application specific queue to deliver the subscription to.
You should then always be able to retrive the messages, worst case as a point to point message with a JMSDestination of type Topic on the message...... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Jun 05, 2007 4:35 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Thanks for the answer.
The messages are going to an application specifi subscriber queue, so that is ok.
I was more interested in the lock condition and how that gets resolved. Either from an administrative perspective or application.
How can the lock be released. Is there a method/procedure, so that the same durable subscriber with the same Client ID can resubscribe and receive the messages? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 05, 2007 4:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There's no need to resubscribe.
That's what you're using a durable subscription FOR - so that it's always there, whether your app is running or not.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Jun 05, 2007 5:06 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
correct, but those delivered subscriptions are for a "specific" subid (I have been using this interchangeably with client id). since the client application has ended abruptly, it need to resubscribe(connect?) using the same subid, which is tied to the messages on the queue. This is where the lock issue comes into play. The broker does not allow this to happen, without the the 3165. The client has had to change it's subid in order to resubscribe to the topic, but as I mentioned before, the previous messages are left on the subscriber queue and cannot be pulled off by the client application in the normal manner(as a subscriber of the topic, with the original subid).
Perhaps I'm missing a subtle point!? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 05, 2007 5:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Um.
So you have more than one application reading subscription messages off an application-specific queue? Or maybe I've missed a subtle point?
With a durable subscription, one almost should really just treat like an administrative thing. That some task or person has the job of setting up the subscription, but the actual consumer doesn't even know that it's receiving subscription messages.
Also, maybe you should be considering using retained publications rather than a durable subscription?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Jun 05, 2007 5:53 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Not to drag this out to far.......................
The Message Broker does publication of EVENT data which it receives from a point to point queue. So the a Message Flow is the publisher. It was decided that because this is EVENT data, and each event is required to build historical information, that durable subscriptions was the best way to go. As opposed to retained publications/subscriber which are better suited to STATE information(only the last matters). Therefore, we went with durable. Durable subscribers have a subid attached to them, making each subscriber unique. This became a problem when the subscriber got abrubtly bumped from is subscription.
So the root of this thread, is how does a durable subscriber reestablish connectivity to the broker with a subid to continue to receive its durable messages under that original subid. The behaviour we see, is that those messages become orphaned to its subscriber. |
|
| Back to top |
|
|
|
|
