| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQRCCF_SUBSCRIPTION_LOCKED |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Tue Aug 28, 2007 5:52 am Post subject: MQRCCF_SUBSCRIPTION_LOCKED |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Queue Manager is:
Windows 2003 SP1
MQ 6.0.2.1 + IC51904 + IC53266
Built in MQ Broker (not WB-IMB / WMB)
JMS Clients using the 6.0.2.1 MQ jars.
Durable Subscribers, non Retained Publications.
Using MO71, I see the following details for this subscription:
Stream Name = SYSTEM.BROKER.DEFAULT.STREAM
Topic = HIG.HLI.ICC.AGENT
Q Name = SYSTEM.JMS.D.SUBSCRIBER.QUEUE
Subscriber Name = JMS:HIGCONL3:AML_APPLICATION:AGENT
Registration Correl ID = 414D5120484947434F4E4C332020202015B7B0462060AC0D
Registration options = 3145729 (Correl ID Identity, Locked, Variable User ID)
This is our LAB environment where we first started. Going forward the app will use a dedicated Stream Q, the Topics will be named with "/"s instead of "."s and the subscriber queues will be split up so that each topic will have its own SYSTEM.JMS.D.* queue and multiple subscribers will share topic queues.
Any-hoo, one of the subscribers is getting MQRCCF_SUBSCRIPTION_LOCKED.
| Quote: |
"MQRCCF_SUBSCRIPTION_LOCKED
Explanation:The subscription is locked. The subscription is currently exclusively locked by another identity.
Programmer Response:Wait for this identity to release the exclusive lock. "
|
That's some good advice, huh? Wait.
What did the subscriber do (wrong?) to get locked? And how do we get them unlocked?
Looking at the optional parms for registering subscribers, I find the below. I don't know if that's how the subscriber got itself like this. Maybe it subscribed with JoinExcl and needs to resubscribe with JoinShared???
| Quote: |
""JoinExcl" (string constant: MQPS_JOIN_EXCLUSIVE, integer constant: MQREGO_JOIN_EXCLUSIVE)
Indicates that the specified SubIdentity should be added as the exclusive member of the identity set for the subscription, and that no other identities can be added to the set. If the subscription is currently exclusively locked, the command fails if the identity with the exclusive lock is not the one in this command message; if it is the same identity, the command succeeds, but returns a warning of MQRCCF_ALREADY_JOINED. If the identity has already joined ’shared’ and is the sole entry in the set, the set is changed to an exclusive lock held by this identity. Otherwise, if the subscription currently has other identities in the identity set (with shared access) the command fails. If an application attempts to register with a SubIdentity and the userid differs from that currently registered with the subscription, it fails if VariableUserId is not set on the original subscription or, if it is set, the userid of the command message is checked for authority to browse the stream queue and put to the subscriber’s queue; if it does not have sufficient authority, the command fails. This option is valid only when SubIdentity is specified. "
""JoinShared" (string constant: MQPS_JOIN_SHARED, integer constant: MQREGO_JOIN_SHARED)
Indicates that the specified SubIdentity should be added to the identity set for the subscription. If the subscription currently has zero or more members in the identity set and none match this identity, and it is not exclusively locked (see "JoinExcl"), the command succeeds and adds this identity to the set.
If the identity already has a shared entry for this subscription, the command succeeds but returns a warning of MQRCCF_ALREADY_JOINED. If the subscription is currently locked exclusively, MQRCCF_SUBSCRIPTION_LOCKED is returned, unless the identity that has the subscription locked is the same identity as the one in this command message, in which case the lock is atomically modified to a shared lock. If an application attempts to register with a SubIdentity, and the userid differs from the one currently registered with the subscription, it fails if VariableUserId is not set on the original subscription. If it is set, the userid of the command message is checked for authority to browse the stream queue and put to the subscriber’s queue; if it does not have sufficient authority, the command fails. This option is valid only when SubIdentity is specified." |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Aug 28, 2007 12:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| This is our LAB environment where we first started. Going forward the app will use a dedicated Stream Q, the Topics will be named with "/"s instead of "."s and the subscriber queues will be split up so that each topic will have its own SYSTEM.JMS.D.* queue and multiple subscribers will share topic queues. |
Peter, just as an aside, can you please share your view point for this decision.
I would have gone the opposite:
Each subscriber has a dedicated publications queue where he receives all published topics... Now it is up to him to separate topics if need be.
The advantage here is if you have a durable subscriber that is not picking up his topics you have less trouble finding the culprit and less interference when you need to change queue depth etc...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 28, 2007 12:50 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, not to seem unfair to Paul Clarke, but I would compare the output of MO71 with the output of amqspsd.
I have heard of subtle bugs in MO71 in other areas (client channel tables, actually).
And then I'd see if you can capture the subscription request that the JMS sender is producing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 29, 2007 4:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
fjb_saper,
We went round and round on this. Eventually I realized it was kinda the same decision as for regular queues. Sure you could have all your apps read / write from a single queue, or you can make a million specific queues, but the right answer is somewhere in between and its a bit art as well as science.
We knew we had to have durable subcribers. We did not want to use dynamic queues. The app area did not want to involve us everytime a new subscriber came on board to define a new queue. The list of topics was going to be very static, as was the # of publishers. Based on that we decided to make 1 stream queue for the publisher, and a dozen subscriber queues named after the topics. If a new subscriber came on board, it would register per topic and connect to one or more "Topic" queues getting by Correl ID to avoid contention.
True, it makes it hard to see how many messages a particular subscriber is getting. On the flip side we can monitor how many messages per topic are going out.
The app reported yesterday afternoon that they were back in business:
| Quote: |
The lock got cleared when User1's stopped the container which had the application running in contention with User2's app.
|
Don't know exactly what that means.  But at this point MO71 still showed the lock on the subscription.
Jeff, good suggestion regarding amqspsd. I was eager to compare that to MO71, but this morning MO71 and amqspsd report the lock is gone for that subscription. This is odd because yesterday after the app area sent the above message that they were OK, the lock was still there, and then this A.M. the lock is gone with no further action on my part.
So am left wondering, How did the lock occur and what happened that got rid of it?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 29, 2007 4:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd say that the app didn't properly close the TCF, and even though User1 had "quit", it still had the subscription lock.
So, as always... an application fault.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
