| Author |
Message
|
| neilgc |
 Posted: Fri Nov 01, 2002 9:19 am Post subject: Put inhibbiting a Queue |
 |
|
Novice
Joined: 03 Jul 2002
Posts: 20
Location: London
|
Not sure if anyone can explain this, we have a queue that has been setup on a server in our hub cluster. An application on another server (running MQSeries Server) puts to this queue which has been shared to this second cluster so that it is visible. We then setup a second instance of this queue (identical name) on our second hub but set it to "put inhibited" as we hadn't depoyed the rest of the application on that server that would process the message. The theory being that if the queue exists on two servers but one is "put inhibited" that the messages would always go to the active queue. However later that afternoon a message appeared on the Dead Letter Queue of the new hub stating that it was placed there because the intended queue was "put inhibited"
Any ideas or have I misunderstood some key concept?
Thanks in advance.
Neil  |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Fri Nov 01, 2002 10:36 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
If you specified the queue and the qm where the first shared queue is physically hosted, then you should always have the messages go to ONLY this queue. But if you put messages on this queue from some other QM that are part of the cluster, then the message follows the round robin algorithm and attempts to put the message to the other instance of the queue. And since it was put inhibited, the message lands up on the DLQ.
My 2 cents.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mfeenstra |
| Posted: Fri Nov 01, 2002 12:48 pm Post subject: |
|
|
Novice
Joined: 03 Jul 2002
Posts: 12
|
It sounds to me like you put the message from the same queue manager that hosts the put-inhibited queue. Meaning the cluster found the queue locally and didn't try sending it across the cluster -- causing it to goto the dead letter queue, due to the fact that it was put inhibited.
I don't think you would ever see this if you put from a queue manager that hosted no instances of that queue.
_________________
Matt Feenstra
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| leongor |
| Posted: Sat Nov 02, 2002 11:35 pm Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
Another option - you use open on bind option.
Thus all messages go to the once opened queue.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| jc_squire |
| Posted: Sun Nov 03, 2002 7:46 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
when using bind on open you cannot specify which queue to bind to - it will only ensure that all messages sent to a specific cluster queue are delivered to the same instance of the queue which was resolved by the cluster workload algorithm at open time i.e. QA exists on QM1 and QM2, application on QM3 opens QA and puts 5 msgs onto the queue, under normal conditions QM3 will evenly distribute/deliver msgs over both queues on QM1 and QM2 but if you specify bind on open it will deliver all 5 messages to the same instance of the queue (e.g. QA on QM1), however, it will not always deliver all messages to QA on QM1 because the workload algorithm will not always resolve to QA on QM1 at open time e.g. closing the queue and opening it again (different object handle) could resolve to QA on QM2 (in this case the application would then bind to QA on QM2 until the queue is closed again).
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| neilgc |
| Posted: Mon Nov 04, 2002 3:50 am Post subject: |
|
|
Novice
Joined: 03 Jul 2002
Posts: 20
Location: London
|
Thanks for the responses. I can confirm that the application is running on a server other than where the Queues are located so it's not a case of putting to a local over a remote queue. The Queues on both hub servers are shared out to the Cluster where the application is running. With this being the case the queues are therefore accessible to the Queue Manager where the application is running. This being the case the app is configured to put to the queue locally.
For clarity I'll us an example
QM_H1 is the Queue Manager on Hub 1
QM_H2 is the Queue Manager on Hub 2
QM_APP is the Queue Manager where the application is running
Q1 is the name of the queue declared on both hubs, and shared out to QM_APP.
The application is configured to place a message on Queue Manager QM_APP, with a Queue name of Q1.
That's still not overly clear but I can't think of a better explanation. Any more ideas? |
|
| Back to top |
|
|
| 2189 |
| Posted: Wed Nov 06, 2002 9:00 am Post subject: |
|
|
Apprentice
Joined: 22 Oct 2002
Posts: 31
|
Mmmm, this sounds real weird. I wouldn't expect with that senario for a message to go to the DLQ where the disabled queue is hosted. Try this for diagnosis:
From an admin session on QM_APP run:
dis qc(Q1) all
this should display both the clustered queues the qmgr can see and will display the PUT setting the qmgr can see. e.g.
dis qc(TEST_TO.QMBKB3T2)
4 : dis qc(TEST_TO.QMBKB3T2)
AMQ8409: Display Queue details.
CLUSTER(CL_PF_POISE)
QUEUE(TEST_TO.QMBKB3T2)
CLUSQMGR(QMMQB3T2)
QMID(QMMQB3T2_2001-12-03_10.28.11)
CLUSQT(QALIAS)
TYPE(QCLUSTER)
PUT(DISABLED)
DEFPRTY(0)
DEFPSIST(NO)
DEFBIND(NOTFIXED)
AMQ8409: Display Queue details.
CLUSTER(CL_PF_POISE)
QUEUE(TEST_TO.QMBKB3T2)
CLUSQMGR(QMMQB3T1)
QMID(QMMQB3T1_2001-12-03_10.27.43)
CLUSQT(QALIAS)
TYPE(QCLUSTER)
PUT(ENABLED)
DEFPRTY(0)
DEFPSIST(NO)
DEFBIND(NOTFIXED)
If they're both ENABLED try a refresh cluster.
If it shows 1 ENABLED and 1 DISABLED then disable the other at the host, rerun the DIS command and see if the change is acknowledged. If it is try putting to the queue again, if it's working properly you should get a 2268 error: MQRC_CLUSTER_PUT_INHIBITED
After that I'm not sure what else to suggest.
_________________
2189 errors make me  |
|
| Back to top |
|
|
| neilgc |
| Posted: Thu Nov 07, 2002 6:04 am Post subject: |
|
|
Novice
Joined: 03 Jul 2002
Posts: 20
Location: London
|
Many Thanks 2189, I'm still fixing the problem but you were spot on with it being a Clustering issue. The Clusters aren't refreshing properly.  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 07, 2002 6:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
OK, dumb question. The message on the DLQ that had the reason as PUT_INHIBITED: what was the destination queue / queue manager.
I just wanna make sure we are looking at a message that was destined for the queue in question before we rack our brains here.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
