| Author |
Message
|
| jainvik7 |
 Posted: Mon Jul 14, 2008 11:06 pm Post subject: Tracking messages |
 |
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
Hi,
I have the current setup
QMGR1 --> Full Repo for cluster named CLUSTER1
QMGR2 --> Full Repo for cluster named CLUSTER1
CL.LOCAL.Q1 --> Local queue on QMGR1 and also in cluster CLUSTER1.
CL.LOCAL.Q1 --> Local queue on QMGR2 and also in cluster CLUSTER1.
I have put disabled both the queues and both the qmgrs have dlq defined for them as SYSTEM.DEAD.LETTER.QUEUE.
TEST.QM1 --> Partial Repo for cluster CLUSTER1.
I try putting messages on CL.LOCAL.Q1 through TEST.QM1.
No errors and no trace of messages found. Even the error logs not updated.
I just wanted to see how this scenario would work. Is this the way its supposed to work? Why no trace of the messages.
MQ version - 5.3 OS - Win.
Your comments are awaited.
Thanks!! |
|
| Back to top |
|
 |
| jainvik7 |
| Posted: Mon Jul 14, 2008 11:37 pm Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
I retried the same thing again (as the post above), and now I get an error stating MQRC_CLUSTER_PUT_INHIBITED.
Not sure why the change in behaviour. Is it because the cluster info is not properly shared between the qmgrs? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 15, 2008 7:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| and now I get an error stating MQRC_CLUSTER_PUT_INHIBITED |
First, this is not an error; rather, this is the reason code the qmgr issued in response to whatever you did. I'll guess that you ran a utility like amqsput to put a message to a clustered queue. Did you? Exactly what command did you issue?
Did you look up the reason code in the Messages manual? What did it tell you? In this case, the reason code tells you why the call failed.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Jul 15, 2008 7:25 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
I think he knows what the 'error' is....his point is that it didn't throw the reason code before when he tried the same thing.
I think it has to do with the partial repository not being notified of the queue attribute change but I always thought that partial repositories didn't automatically get refreshed until a refresh interval was reached or it was explicitally told to refresh....but I could be wrong. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 15, 2008 7:36 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I have put disabled both the queues |
In the original post, jainvik7 tells this. A subsequent MQPUT attempt will fail since no instance of the clustered queue is put(enabled).
| Quote: |
No errors and no trace of messages found. Even the error logs not updated.
I just wanted to see how this scenario would work. Is this the way its supposed to work? Why no trace of the messages. |
This is exactly how it is supposed to work. This is not an error, but is an expected behavior as documented in the WMQ Application Programming Reference and WMQ Application Programming Guide: a reason code is handed back to the application program. It is up to the application to take whatever action the business rules dictate.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Tue Jul 15, 2008 8:14 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
Yep that happens.. The reason is that it takes some time for the information about the change in attributes of the Q to propagate.. shall I say a cluster refresh is required to get a 2268 return code, at the time of putting the first message on the disabled Q's.
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 15, 2008 8:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I try putting messages on CL.LOCAL.Q1 through TEST.QM1. |
Did you successfully put messages to the queue?
| Quote: |
| I retried the same thing again (as the post above), and now I get an error stating MQRC_CLUSTER_PUT_INHIBITED. |
Back to the original post: what did you try the first time that worked? Were the clustered queues put(enabled) then? You didn't say.
From your original post, you put(disabled) all clustered queues. Is that what you did on your next attempt?
Please explain in more detail: what did you try first? What results did you receive?
Then: What did you try next? What results did you receive?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Tue Jul 15, 2008 8:44 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
Would like to tell u the same thing.. dont just post post post.. TEST .. TRY.. and then POST.. I suggest u test out this scenario..
_________________
*forgetting everything * |
|
| Back to top |
|
|
| jainvik7 |
| Posted: Tue Jul 15, 2008 11:49 pm Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
Guys,
Thanks for the response and sorry for the the confusion. I should have used the terms properly (as for error and reason code).
To clear our doubts -->
1. I used the amqapi.exe to put the messages which I believe is as good as any other program.
2. I wrongly used the term error instead of Reason Code.
3. On the first try, after put disabling the queues, I tried putting some messages in an expectation that I would not be able to. But to my surprise I was able to with out any Reason code. Now just because I was able to put messages, I wondered where these messages would have landed as the queues were PUT DISABLED. I was not able to find those in the Dead letter queues and also no error messages were found in the error logs (AMQERR01) stating the probable reason why the messages were not in the queues.
4. After investigating for a few minutes, I tried the same steps again to put the messages and I got the reason code as mentioned above.
So my doubt remains for the first attempt.
Now, why did I do all this.
We are into production support of an WBIMB application where we have few servers running. One of the servers has been out of service for sometime but just because it holds the Full repository, the input clustered queues are put disabled so that this server does not process any incoming messages. But time and again we get some messages on the dead letter queue of this server and the dead letter header indicates a reason code of queue being put disabled. But when I see the queue properties, its not been altered for quite some time. So, ideally, I should not get any messages on this server, but sometimes I do. The only probable reason I can think of is that the repository info is not shared across consistently.
I just wanted everyone's opinion on this.
Hope I am clear with my doubt/explanation here.
Thanks!! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 16, 2008 5:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If QueueA lives on QM1 and QM2 in a cluster, and you put inhibit QueueA on QM1 only, load balancing will send all new messages to QM2. UNLESS the sending application specifically addresses them to QueueA on QM1. In that case the messages will go to QM1, and once there, into the DLQ.
Same thing with a suspended QM. It does not prevent messages from going to the suspended QM if the messages are specifically addresses by the sender to go to that QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 16, 2008 5:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| But to my surprise I was able to with out any Reason code. |
Are you saying that the amqapi.exe application ended without returning a reason code; AND that you could not find your messages in either of the clustered queues OR dead-letter queues? Is this correct?
I don't have an WMQ image at moment; but here's a guess: if amqapi behaves like amqsput, the application requires you enter some kind of data at stdin that becomes the application data in the message. Pressing the enter key on a null line (or failing to enter any application data) will end the program, and result in NO message being MQPUT to a queue; AND you would get no reason code. This is normal behavior for most of the supplied utilities.
If you have the entire c: prompt interaction saved somewhere? If so, include it in your post.
Edit: Oddly, this is the behavior of the supplied utilities amqsput, amqsget, amqsbcg...).
These applications do not tell you MQRC_NONE. They also do not tell you, for example, that 1 message (or zero, in this case), was put to a queue.
Best practice for a business application would be to include counts of messages that were successfully put, or failed to be put to a queue.
The utilities are what they are. They are sample programs that can demonstrate functionality of mq - within the limits of what the utilities offer.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Wed Jul 16, 2008 6:16 am; edited 2 times in total |
|
| Back to top |
|
|
| jainvik7 |
| Posted: Wed Jul 16, 2008 6:13 am Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
| Quote: |
Are you saying that the amqapi.exe application ended without returning a reason code; AND that you could not find your messages in either of the clustered queues OR dead-letter queues? Is this correct?
|
Yes, infact I tried putting multiple messages through the amqapi.exe and the PUTs were successful. Thats the reason, I tried to investigate where the messages went. Are they lost without a trace and also no logging? That is what surprises me.
For more clarity, the following is what I did with amqapi.exe
1. MQCONN to TEST.QM1 (MQCC = OK, MQRC = OK).
2. MQOPEN to queue CL.LOCAL.Q1 with MQOO_OUTPUT selected (MQCC = OK , MQRC = OK )
3. MQPUT with some sample text (MQCC = OK, MQRC = OK)
4. MQPUT with some sample text (MQCC = OK, MQRC = OK)
5. MQPUT with some sample text (MQCC = OK, MQRC = OK)
6. MQPUT with some sample text (MQCC = OK, MQRC = OK)
7. MQPUT with some sample text (MQCC = OK, MQRC = OK)
8. MQPUT with some sample text (MQCC = OK, MQRC = OK)
9. MQCLOSE (MQCC = OK, MQRC = OK)
10 MQDISC (MQCC = OK, MQRC = OK)
But after this no trace of the messages. Thats what confused me.
I expected the messages to be there in the DLQ and couldnt find them there. Perplexed, I tried again after a few minutes, but then i got the RC = MQRC_CLUSTER_PUT_INHIBITED.
Hope this clarifies. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 16, 2008 10:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Dead-letter queue exist on queue managers?
Queue manager object altered to know the name of the dead-letter queue?
Dead-letter queue put(enabled)?
Non-persistent messages?
NPMSPEED(FAST) specified on clussdr or clusrcvr channel definitions?
After step 10, did you stop the qmgr and restart it?
Edit: If you put persistent messages, you could run the dmpmqlog command and look through the output for your message(s). Refer to the WMQ System Admin manual for dmpmqlog command parameters.
Is this problem repeatable?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jainvik7 |
| Posted: Wed Jul 16, 2008 8:01 pm Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
Thanks Bruce!!
My answers to your queries in BLUE
| bruce2359 wrote: |
Dead-letter queue exist on queue managers? YES
Queue manager object altered to know the name of the dead-letter queue? NO
Dead-letter queue put(enabled)? YES
Non-persistent messages? YES
NPMSPEED(FAST) specified on clussdr or clusrcvr channel definitions? YES
After step 10, did you stop the qmgr and restart it? NO
Edit: If you put persistent messages, you could run the dmpmqlog command and look through the output for your message(s). Refer to the WMQ System Admin manual for dmpmqlog command parameters. WILL TRY THIS
Is this problem repeatable? NO |
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jul 17, 2008 11:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Queue manager object altered to know the name of the dead-letter queue? NO |
If you haven't set the DEADQ attribute, then you have no dead-letter queue.
WMQ doesn't lose messages. However, you may create the set of circumstances where you direct WMQ to discard messages - and you've done so.
If you send non-persistent messages AND have specified NPMSPEED(FAST) channel attribute AND the downstram message channel agent (MCA) can't put the message in the destination queue because the queue doesn't exist or is full OR put disabled OR the message is too big for the queue; then the MCA tries to put the message in the dead-letter queue.
If the dead-letter queue doesn't exist (and in your case, it doesn't exist because you didn't alter the DEADQ attribute of the qmgr to know the name of the dead-letter queue) OR the dead-letter queue is put disabled OR the message is too big for the queue; then WMQ discards the message.
It appears that when you MQOPENed the queue, the local qmgr found the clustered definition of the queue put(enabled) and you successfully put messages to the transmission queue. When the messages arrived at the downstream qmgr, that qmgr found the queue put(disabled); and according to the above rules, discarded your messages.
This is behaving as documented in the WMQ Intercommunications manual.
No need to run dmpmqlog because non-persistent messages are not logged.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
