| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Tracking messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Thu Jul 17, 2008 6:10 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
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.
|
... or the DLQ is full ...
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Jul 17, 2008 8:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
That, too.
_________________
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: Thu Jul 17, 2008 9:08 pm Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
Bruce,
| Quote: |
| Queue manager object altered to know the name of the dead-letter queue? NO |
When I said I did not alter the qmgr, I meant that I did not alter the qmgr after I created it. What I mean to say here is that I had created the qmgr with the dlq defined for that. Please refer to my original post. I had mentioned that all the qmgrs have the dlq defined for them.
So ideally I should have found the messages on the dlq?
And in any of the scenarios mentioned/discussed in this discussion, I would have have expected something to be logged in the AMQERR01 file. But that is not the case. This is what leaves me more confused.
Hope this clarifies.
Thanks. |
|
| Back to top |
|
|
| mlr |
| Posted: Thu Jul 17, 2008 11:00 pm Post subject: |
|
|
Novice
Joined: 29 Jun 2008
Posts: 13
|
| if you want to keep the msgs no matter what, make them persistent. wmq discards non-persistent msgs if there is a problem deliviering them. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 18, 2008 8:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I would have have expected something to be logged in the AMQERR01 file. |
An unrealistic expectation, given the narrative (Intercommunications, APR and APG) about non-persistent messages across FAST channels.
Do a search through the WMQ Messages manual, and you will discover no entries about non-persistent messages.
Since you cannot repeat this scenario, I'd strongly suggest using persistent messages; and if you can't, then at least set NPMSPEED(NORMAL) so that the MCA sends all messages in units of work. Make sure your application programs request the appropriate report messages so that the app will be notified of downstream failures to deliver.
The utility you used is bare-bones - it is not a good model for a business application.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sat Jul 19, 2008 8:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mlr wrote: |
| wmq discards non-persistent msgs if there is a problem deliviering them. |
More often than not MQ does not discard even non persistent messages when there is a problem delivering them.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 19, 2008 10:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| wmq discards non-persistent msgs if there is a problem deliviering them |
Not the case. WMQ wants to deliver all your messages, both persistent and non-persistent.
There are specific requirements that must be met for WMQ to discard non-persistent messages. These are well-documented in the APG, APR and Intercommunications manuals.
_________________
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: Sat Jul 19, 2008 1:18 pm Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
Err.. whats the discussion about.. I posted earlier that.. even I tested this scenario and it returns an error only after some time.. not at the first put.
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| sami.stormrage |
| Posted: Sat Jul 19, 2008 11:14 pm Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
| Quote: |
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.
|
Bruce.. something called the Qname resolution happens which.. decides where the messages go from the sending Qmgr..
_________________
*forgetting everything * |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jul 20, 2008 8:53 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Bruce.. something called the Qname resolution happens which.. decides where the messages go from the sending Qmgr.. |
Saying that something exists does not add value to the conversation.
Why is name resolution important here? What are the implications of cluster definitions?
The name resolution process is documented in the Intercommunications manual, as well as other manuals.
Name resolution takes place at MQOPEN (or MQPUT1, which does an implied MQOPEN).
When an application issues an MQOPEN or MQPUT1, the local (where the application is running) qmgr searches for a definition whose name matches the name in the MQOD (object descriptor), the name that the application tries to open).
The qmgr first searches for locally defined QLocal, QModel, QAlias, QRemote; then, if no matching definition is found, the partial repository is searched; then if no matching definition is found, the full repository is searched.
If the name the application opens resolves to a transmission queue, then the sending MCA flows the message downstream. The receiving MCA drives name resolution on its local qmgr - using the same search order.
My suspicion is that the application succeeded MQOPENing the most recent (as seen by this qmgr) clustered object definition because the most recent (as seem by the local qmgr) definition was put(enabled). Result: MQPUTs succeeded.
Why? Because when the queue was put(inhibited) on the remote qmgr, the updated - put(inhibited) - definition had not yet been routed to the qmgr where the application was running. Again, name resolution takes place at MQOPEN. If the definition was local to the application, then the next MQPUT would have failed.
At next MQOPEN, the updated definition showed put(inhibited). Result: Name resolution could not find a put(enabled) definition.
My suspicion is that the dead-letter queue at the downstream qmgr did not exist (or was not available), and that the non-persistent messages were discarded. WMQ does not issue errors about non-persistent messages that are discarded. This is working as designed. This is repeatable.
The supplied utilities are tools to do elementary testing, like: can I open a queue? can I put a message? can I get a message, and so on.
Adding clustered definition adds some more complexity to the problem as perceived and described in the original post.
The Intercommunication manual, together with the APG and APR describe this behavior. This is working as designed and documented.
From all this, best practice coding would call for persistent messages, NORMAL channels, available dead-letter queues, request messages with exception report options.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
