| Author |
Message
|
| fjb_saper |
 Posted: Tue May 25, 2010 11:02 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| fatherjack wrote: |
I'd still be interested in what fjb_saper's 'etc.' includes. |
The etc includes stuff like XMS and other support packs / addons that might supply you with the same functionality... 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| fatherjack |
| Posted: Tue May 25, 2010 12:24 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| fjb_saper wrote: |
| The etc includes stuff like XMS and other support packs / addons that might supply you with the same functionality |
OK thanks for that. But basically applications rather than out of the box MQ functionality.
Interesting really as in the old days (circa 1996) it was always recommended that one didn't write applications to put poison messages to the DLQ (the DLQ was just for undeliverable messages) but rather put them to an application specific poison message queue, yet nowadays here we have IBM doing just the opposite.
What's everyone else doing these days?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 25, 2010 12:37 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fatherjack wrote: |
Interesting really as in the old days (circa 1996) it was always recommended that one didn't write applications to put poison messages to the DLQ (the DLQ was just for undeliverable messages) but rather put them to an application specific poison message queue, yet nowadays here we have IBM doing just the opposite.
|
IBM does that if the MQ Admin negleted to specify the Backout Q parameter on the input queue.
The apps get application specific backout / poison / exception queues here. The system DLQ is for system messages only! I don't want to get paged because of some apps message that coulda / shuda went to an app specific backout queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fatherjack |
| Posted: Tue May 25, 2010 12:48 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| PeterPotkay wrote: |
| IBM does that if the MQ Admin negleted to specify the Backout Q parameter on the input queue. |
OK. Of course. But what if the MQ Admin neglected to specify a DLQ
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 25, 2010 12:56 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fatherjack wrote: |
| PeterPotkay wrote: |
| IBM does that if the MQ Admin negleted to specify the Backout Q parameter on the input queue. |
OK. Of course. But what if the MQ Admin neglected to specify a DLQ |
What happens when you try it? |
|
| Back to top |
|
|
| fatherjack |
| Posted: Tue May 25, 2010 1:39 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| mqjeff wrote: |
| What happens when you try it? |
Hi mqjeff,
Sorry I didn't mean I don't know technically what happens. I was just trying to elicite others thoughts regarding the use of BOQ and DLQs. So, for example, given what does happen, is it the right approach to even try and put messages from a [business] app to the DLQ or should we just leave that to system apps like the MCA?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue May 25, 2010 1:51 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
My two penneth...
The DLQ is termed by IBM as an undelivered-message queue and as far as I am concerned a poison message is NOT undelivered (in WMQ terms anyway); therefore (by definition) every application should have its own back-out queue should it need it.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 25, 2010 1:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
My 2 cents:
If the message is rolled back by WMB in response to an error, there's no BOQ & no DLQ you discover why they're called poison messages as your flow dies a slow and painful death.
| fatherjack wrote: |
| what if the MQ Admin neglected to specify a DLQ |
Then the MQ Admin should die a slow and painful death. I don't want to reignite any debate on the use (or not) of SYSTEM.DEAD.LETTER.QUEUE but IMHO there's no excuse for not setting something as the DLQ.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Tue May 25, 2010 2:25 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| Vitor wrote: |
| there's no excuse for not setting something as the DLQ. |
Absolutely have to agree but I also agree with the following....
| exerk wrote: |
| The DLQ is termed by IBM as an undelivered-message queue and as far as I am concerned a poison message is NOT undelivered (in WMQ terms anyway); therefore (by definition) every application should have its own back-out queue should it need it. |
So, should WMB or any user-written application for that matter, stuff messages on the DLQ just because it doesn't recognise them? I don't think so. It's not an 'architecturally sound' thing to do.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue May 25, 2010 2:58 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
This post site has many examples of MQ things used for other than their intended purpose. Caveat emptor.
A full or non-existent (or put-inhibited or insufficient max msg length) DLQ can lead to otherissues (discarded non-persistent msgs on an npmspeed fast channel, or a failed channel if a destination queue is unavailable.
At the very least, and as a best-practice, the dead-letter handler should move messages off the system-defined DLQ. If messages are moved off the DLQ, then the application (or flow) should put 'defective' messages on an application-oriented queue specific to that purpose.
_________________
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 |
|
|
| fjb_saper |
| Posted: Tue May 25, 2010 8:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
One of the reasons for using the DLQ instead of a BOQ is to have a DLQ handler forward the messages to the application queue. After inspection you can use a DLQ handler to process (retry) or discard the messages as long as the same rule applies to all messages with the same characteristics... So basically what you get is a BOQ equivalent but the messages have a DLQH on them...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 26, 2010 12:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...A full or non-existent (or put-inhibited or insufficient max msg length) DLQ can lead to other issues (discarded non-persistent msgs on an npmspeed fast channel)... |
I don't see this as an issue if the decision has been made by the sending end that the messages are that unimportant. And in the past I have found that setting the maxmsglen on the DLQ is one way of 'trapping' apps that start pushing the boundaries beyond the stated agreement.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 26, 2010 2:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| exerk wrote: |
I don't see this as an issue if the decision has been made by the sending end that the messages are that unimportant. And in the past I have found that setting the maxmsglen on the DLQ is one way of 'trapping' apps that start pushing the boundaries beyond the stated agreement. |
I would have thought you'd set the maxmsglen on the app / xmit Q and trap the messages in the DLQ. What purpose serves setting the maxmsglen in the DLQ? It may affect adversely other applications running on the same qmgr...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 26, 2010 2:22 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| exerk wrote: |
I don't see this as an issue if the decision has been made by the sending end that the messages are that unimportant. And in the past I have found that setting the maxmsglen on the DLQ is one way of 'trapping' apps that start pushing the boundaries beyond the stated agreement. |
I would have thought you'd set the maxmsglen on the app / xmit Q and trap the messages in the DLQ. What purpose serves setting the maxmsglen in the DLQ? It may affect adversely other applications running on the same qmgr... |
Because I don't always have control over the channels/XMITQ's (a consequence of how definitions are run-in), but I do have control over my DLQ's  - of course it doesn't work where the messages are way smaller than maxmsglen and 'grow' just a bit, but it's BIG messages getting bigger and impacting logging that are of major concern to me.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
