|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Should the DLQ on a Queue Manager *must* be a local queue on |
« View previous topic :: View next topic » |
Author |
Message
|
mqdev |
Posted: Tue Apr 03, 2012 6:52 am Post subject: Re: PMR response.... |
|
|
Centurion
Joined: 21 Jan 2003 Posts: 136
|
mqjeff wrote: |
mqdev wrote: |
Now once the xmitq itself gets full, the QM would start dumping the msgs on the DLQ. Once the DLQ also gets full, the next msg would go into a infinite loop... |
No.
Once teh DLQ also gets full, the MQPUT fails with an MQCC!=0. |
The last msg (which might break the camel's back) does not have be locally PUT. It can be msg ending up the local QM by virtue of this QM being a part of a multi-hop communication chain. What happens then? |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Apr 03, 2012 6:57 am Post subject: Re: PMR response.... |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
mqdev wrote: |
mqjeff wrote: |
mqdev wrote: |
Now once the xmitq itself gets full, the QM would start dumping the msgs on the DLQ. Once the DLQ also gets full, the next msg would go into a infinite loop... |
No.
Once teh DLQ also gets full, the MQPUT fails with an MQCC!=0. |
The last msg (which might break the camel's back) does not have be locally PUT. It can be msg ending up the local QM by virtue of this QM being a part of a multi-hop communication chain. What happens then? |
If it can't be put on the receiving queue, it's rolled back to the remote xmitq.
In the case of a multi-hop, the receiving queue is the xmitq for the remote qmgr. which is already full. |
|
Back to top |
|
 |
mvic |
Posted: Tue Apr 03, 2012 6:57 am Post subject: Re: PMR response.... |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
mqdev wrote: |
The so-called loop scenario can occur even if the DLQ is a local Q on the QM. |
Not sure it's a loop, but, yeah.. something could prevent the queue manager putting to the DLQ (eg. DLQ is full). Or your dead letter queue handler could fail to handle the messages on the DLQ. We live in a non-zero-risk world.
Quote: |
So we are left with "mama knows the best - just do as I say" kind of response without any concrete reason as to why it has to be that way. We are trying to see if we can approach the design team in Hursley to get this answered. In the meantime, ex-IBMers on the forum - can you please chip in? |
You want something better than you got above? You are unlikely to get that from the forum (from ex-IBM people or anyone else for that matter) - you're most likely to get it by telling IBM why you are not satisfied with the answer you got. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Apr 03, 2012 7:35 am Post subject: Re: PMR response.... |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqdev wrote: |
The last msg (which might break the camel's back) does not have be locally PUT. It can be msg ending up the local QM by virtue of this QM being a part of a multi-hop communication chain. What happens then? |
No, a message that's multi-hopping is still being locally put by the receiver MCA of that channel on the queue manager. This will get a non-zero code on the put, the message will roll back to the previous xmitq (where there must be room because the message came from there) and the channel will stop. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Apr 03, 2012 7:36 am Post subject: Re: PMR response.... |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mvic wrote: |
you're most likely to get it by telling IBM why you are not satisfied with the answer you got. |
If you don't like the resolution of the PMR, tell them. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mqsiuser |
Posted: Tue Apr 10, 2012 1:09 am Post subject: |
|
|
 Yatiri
Joined: 15 Apr 2008 Posts: 637 Location: Germany
|
bruce2359 wrote: |
Keep in mind that a DLQ is a special-purpose object, with specific use for by and for the qmgr and MCAs on this qmgr. The qmgr expects its DLQ to be a real local queue on this qmgr. |
A consultant, who worked for production control on a very large Broker&MQ installation said once to me: If there are messages on (production) DLQs, then there must have been a network problem...
From my experience (on development) there can also be problems with channel-setup(-mqsc-scripts) !
If there are network problems... then there likely is almost no way out any more, thats why it makes very much sense to me that (the vendor says that) the DLQ must be a local queue.
mqjeff wrote: |
Once the DLQ also gets full, the MQPUT fails with an MQCC!=0. |
I have been looking at QMGRs, where the DLQ was full... nothing bad with the qmgr (no looping/blocking msgs)... nothing terrible happens then (if the DLQ is a local queue) ... I was like... "oh, look, the DLQ is full... aha (almost didn't notice it)"... the msgs were old and not important for what we were doing currently (also it was a dev/test qmgr).
When the xmit queue is full and the putting app is receiving "cannot put"... when is it that msgs get moved to the DLQ ?
If the DLQ is full: Do msgs potentially get lost then ?! _________________ Just use REFERENCEs |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Apr 10, 2012 3:18 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
mqsiuser wrote: |
I have been looking at QMGRs, where the DLQ was full... nothing bad with the qmgr (no looping/blocking msgs)... nothing terrible happens then (if the DLQ is a local queue) ... I was like... "oh, look, the DLQ is full... aha (almost didn't notice it)"... the msgs were old and not important for what we were doing currently (also it was a dev/test qmgr). |
Are you expecting loud alarm bells, klaxons, flashing red lights, when the DLQ reaches maxdepth? DLQ at maxdepth is merely an event, not a catastrophe for WMQ.
mqsiuser wrote: |
When the xmit queue is full and the putting app is receiving "cannot put"... when is it that msgs get moved to the DLQ ? |
Never. If the xmit queue is full, all that happens is that the putting app receives a MQRC_Q_FULL ReasonCode - theere is NO message.
mqsiuser wrote: |
If the DLQ is full: Do msgs potentially get lost then ?! |
WMQ does not lose messages; but in specific circumstances, you/your app/your admins may direct WMQ to discard a message. This is well-documented in the WMQ Intercommunications manual, and here. _________________ 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 |
|
 |
bruce2359 |
Posted: Tue Apr 10, 2012 4:01 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
mqsiuser wrote: |
A consultant, who worked for production control on a very large Broker&MQ installation said once to me: If there are messages on (production) DLQs, then there must have been a network problem... |
This is only partially true. There are other reasons a message might end up in the DLQ.
If, for example, a trigger fails to launch an application, the trigger message may end up in the DLQ on the qmgr where the trigger failed. Not network problem in this instance.
If, for example, you've specified CONVERT(YES) on a Sender channel, AND message data conversion is needed, AND the message data conversion fails, the unconverted message may end up in the DLQ of the Sender qmgr. No network problem in this instance.
As a consultant, I offer this bit to clients: A DLQ is not a requirement - not mandatory for WMQ to execute. A DLQ has benefits for your applications. _________________ 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 |
|
 |
mqsiuser |
Posted: Tue Apr 10, 2012 4:29 am Post subject: |
|
|
 Yatiri
Joined: 15 Apr 2008 Posts: 637 Location: Germany
|
bruce2359 wrote: |
As a consultant, I offer this bit to clients: A DLQ is not a requirement - not mandatory for WMQ to execute. A DLQ has benefits for your applications. |
So ... I guess it is always the responsibility (of the applications/programs) to put msgs on dead letter queues (if quite some other things failed?)... this is not perfectly obvious today, since there often is software "in between" (your own software/code and MQ (e.g. a JMS-Driver))... which actually do exactly this (for you) ?! ... (o.k. you can configure it.)
Also: It seem that it 'kind of' is part of the concept of the DLQ that it is local: A save place to drop of your hot potato (in case you don't want it to be intentionally discarded (as you wrote))... all in the control of your application/software/program that interacts with the qmgr ?!
Thanks for helping me (understand mq better), btw  _________________ Just use REFERENCEs |
|
Back to top |
|
 |
Vitor |
Posted: Tue Apr 10, 2012 4:54 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqsiuser wrote: |
So ... I guess it is always the responsibility (of the applications/programs) to put msgs on dead letter queues (if quite some other things failed?)... this is not perfectly obvious today, since there often is software "in between" (your own software/code and MQ (e.g. a JMS-Driver))... which actually do exactly this (for you) ?! ... (o.k. you can configure it.) |
As a consultant , I advise(d) clients never to allow applications to put messages to the DLQ. It's for the queue manager's use in connection with undeliverable messages it's not allowed to discard. This is a situation which should not happen in a properly configured queue manager with properly configured channels and a working network. Hence it should always be empty and the most simple minded montioring solution can detect queue depth zero -> queue deplth one and sound an alert.
Applications should use backout queues. Or some other queue. If the application wants to add a DLH to it's error messages so they can be retried by the dead letter handler there's no problem. But the last thing I want to face at 8am (or as I call it 3rd coffee) is to find that the mayhem described above is in progress because some application had a nightmare and filled the DLQ with it's error messages.
mqsiuser wrote: |
Also: It seem that it 'kind of' is part of the concept of the DLQ that it is local: A save place to drop of your hot potato (in case you don't want it to be intentionally discarded (as you wrote))... all in the control of your application/software/program that interacts with the qmgr ?! |
Better control is obtained from seeing which of the backout queues is full of error messages, and notifying the development team which owns that queue they seem to have an issue but the queue manager is fine & thanks for asking. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
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
|
|
|
|