| Author |
Message
|
| aotto1968-2 |
 Posted: Mon Aug 21, 2006 2:56 am Post subject: avoid sending messages into SYSTEM.DEAD.LETTER.QUEUE |
 |
|
Newbie
Joined: 21 Aug 2006
Posts: 4
Location: Munich
|
Dear Admin,
I want to avoid sending messages into SYSTEM.DEAD.LETTER.QUEUE
after exceeding the maximum number of messages (MAXDEPTH) from
a LOCAL non-persistent queue
question:
How I have to modify the queue to achive this task?
-> thanks a lot
mfg
aotto |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Aug 21, 2006 3:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
1) Define a different queue to be the dead letter queue
2) Increase the MAXDEPTH of the recieving queue
3) Fix the receiving application so that messages don't back up so badly
So is your scenario this: you have a local queue likely to receive non-persistent messages. If the queue fills up you don't want the messages to go to the dead letter queue.
Is this correct? If it is, what do you want to happen to the undeliverable messages? Where should they go? Why will the queue fill to this level? Can the sending application be signalled in any way to stop and then restart transmission?
A few more details please. Certainly out of the box any message undeliverable due to maxdepth will go to the dead letter queue. The only way to stop that would be to not have a dead letter queue - as these are not persistent messages they will be discarded. This is a very bad thing to do. If you do not have a dead letter queue and a persistent message is ever undeliverable bad things will happen...... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Aug 21, 2006 3:14 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Vitor wrote: |
1) Define a different queue to be the dead letter queue
2) Increase the MAXDEPTH of the recieving queue
3) Fix the receiving application so that messages don't back up so badly
|
4) supply your own message retry exit (MREXIT), then you can do what-ever you like with un-deliverable messages .....
_________________
-wayne |
|
| Back to top |
|
|
| aotto1968-2 |
| Posted: Mon Aug 21, 2006 4:13 am Post subject: |
|
|
Newbie
Joined: 21 Aug 2006
Posts: 4
Location: Munich
|
| Vitor wrote: |
1) Define a different queue to be the dead letter queue
2) Increase the MAXDEPTH of the recieving queue
3) Fix the receiving application so that messages don't back up so badly
So is your scenario this: you have a local queue likely to receive non-persistent messages. If the queue fills up you don't want the messages to go to the dead letter queue.
Is this correct? If it is, what do you want to happen to the undeliverable messages? Where should they go? Why will the queue fill to this level? Can the sending application be signalled in any way to stop and then restart transmission?
|
1. Where should they go -> they should be deleted
2. Why will the queue fill to this level? -> the queue has been filled up by an application beyond my control
3. the data is only just short-time important and can be re-created -> the core problem is to avoid filling up the queue with data out of importance
4. it is possible to create a specific SYSTEM.DEAD.LETTER.QUEUE only used by this special local queue? -> how I can do this? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 21, 2006 4:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
1) Thought so
2) You need to make the reading application go faster
3) There is a better answer - see below
4) The dead letter queue is defined at queue manager level so you can't set one for a specific queue.
The best solution for your problem (and one I accept may be beyond your control) is for the sending application to set the EXPIRY attribute on the messages. Expired messages don't count towards the queue depth and are automatically deleted by the queue manager as part of the housekeeping. This should bypass your problem by improving reading application efficentcy as it's only presented with valid messages and is not wading through stuff out of importance.
If the sending app can't be changed, you'll need to filter the inbound queue somehow. There's no facility within MQ to do what you're proposing out of the box. You could, as wschutz suggests, write an exit but that's an advanced technique. There's been some discussion in here about exits and clearly they're documented, but not for the faint hearted.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 21, 2006 4:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You might also want to research various ways of running multiple copies of the reading program so as to keep pace with the putting application. Depth triggering, multiple copies, clustering (though that costs money in terms of kit and license of course ).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Aug 21, 2006 5:38 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| 4. it is possible to create a specific SYSTEM.DEAD.LETTER.QUEUE only used by this special local queue? -> how I can do this? |
not directly, but indirect. the messages will hit the DLQ that is defined in the queuemanager first. then you can have a DLQ-Handler (it is provided by IBM, see administration guide) and a little rule table to move the messages, that are related to that queue, off the DLQ to a different queue. you could also discard the messages instead of moving them if you like, based on your selection, e.g.
REASON(2053) DESTQ(SCREWEDUPAPPLICATIONQ) ACTION(DISCARD)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 21, 2006 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Mr Butcher,
Lateral thinking - I like it 
I still think aotto1968-2 would be better off exploring other options. It seems odd to me that if the queue is filled with out of date information, the design requirement is to delete the newer, more relevant stuff until the queue empties..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Aug 21, 2006 10:02 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
.....why not set a message expiry if the messages only have a short time to live?...this is, after all, what it is there for. 
Unless the application is totally outside of the control of the control of your shop. If this is the case.....ask the third party to consider designing this into their system.
Failing that then the DLH is by far the easiest and quickest to implement |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 21, 2006 11:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vitor wrote: |
| The best solution for your problem (and one I accept may be beyond your control) is for the sending application to set the EXPIRY attribute on the messages. |
| kevinf2349 wrote: |
.....why not set a message expiry if the messages only have a short time to live?...this is, after all, what it is there for.
|
Is there an echo in here???? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Aug 22, 2006 12:01 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| kevinf2349 wrote: |
.....why not set a message expiry if the messages only have a short time to live?...this is, after all, what it is there for.
Unless the application is totally outside of the control of the control of your shop. If this is the case.....ask the third party to consider designing this into their system.
Failing that then the DLH is by far the easiest and quickest to implement |
Messages, which are put to the DLQ before they have expired will not automatically deleted. You have first to browse the DLQ (e. g. using the DLH), to remove the expired messages.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 22, 2006 12:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| HubertKleinmanns wrote: |
| Messages, which are put to the DLQ before they have expired will not automatically deleted. You have first to browse the DLQ (e. g. using the DLH), to remove the expired messages. |
If you've got the expiry set to a decent value, and an application that's not powered by a rubber band, this should prevent messages going to the DLQ because the queue's full. Hence using DLQ as Mr Butcher suggests or expiry as I and kevinf2349 have are sort of either or solutions to this specific problem.
I do take your point more generally though, and it comes back to proper handling of the DLQ.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Aug 22, 2006 1:19 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
If the reading application is active, but too slow, a setting of the message retry attrributes on the receiving channel end may also be helpful. Then the receiver waits a while and tries several times, to put messages to the target queue. Message in the XmitQ of the sender QMgr, which expire in the meantime, will not be transported, because the sender MCA deletes ist.
So a - meaningful - combination of several mechanisms should help.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
