ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Should the DLQ on a Queue Manager *must* be a local queue on

Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4, 5
 Should the DLQ on a Queue Manager *must* be a local queue on « View previous topic :: View next topic » 
Author Message
mqdev
PostPosted: Tue Apr 03, 2012 6:52 am    Post subject: Re: PMR response.... Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Tue Apr 03, 2012 6:57 am    Post subject: Re: PMR response.... Reply with quote

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
View user's profile Send private message
mvic
PostPosted: Tue Apr 03, 2012 6:57 am    Post subject: Re: PMR response.... Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Apr 03, 2012 7:35 am    Post subject: Re: PMR response.... Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Apr 03, 2012 7:36 am    Post subject: Re: PMR response.... Reply with quote

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
View user's profile Send private message
mqsiuser
PostPosted: Tue Apr 10, 2012 1:09 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 10, 2012 3:18 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
bruce2359
PostPosted: Tue Apr 10, 2012 4:01 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
mqsiuser
PostPosted: Tue Apr 10, 2012 4:29 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Apr 10, 2012 4:54 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3, 4, 5 Page 5 of 5

MQSeries.net Forum Index » Clustering » Should the DLQ on a Queue Manager *must* be a local queue on
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.