| Author |
Message
|
| fjb_saper |
 Posted: Fri Feb 11, 2005 1:25 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
I guess I was looking at it more like a 2 pronged solution
a) for the case where we know what the problem is:
like wrong qname, wrong qmanager etc and don't want to set up aliases ==> set up a rule
b) for messages you want to replay and other non rule resolved cases
forward to a secondary DLQ with alert and human intervention
This means something like
destq(*) action(fwd) fwdq(my.dead.letters) header(yes)
So in fact I would be splitting my DLQ in 2.
a) Cases that can be automatically resolved -- no human intervention needed which means you cannot really do a retry in those rules. As Jeff stated you would risk creating an infinite loop.
b) Cases needing human intervention and analysis
analysis to determine what caused the condition
Intervention to resolve it. Even if that intervention is wait half an hour for the queue to drain as it could not hold all the messages....
Enjoy  |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Feb 11, 2005 1:45 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Never really understood DLQ handlers...
If its something that can be scripted, then its something you are anticipating, which means why don't you fix the condition ahead of time.
If all you are going to do is move the messages from SYSTEM.DEAD.LETTER.QUEUE to MY.DLQ, why not just make MY.DLQ the QM's DLQ to begin with?
Messages goig to a DLQ mean something is screwed up. It needs to be looked at manually. We get paged when our DLQs > 10. We get emails when the DLQ > 0.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 11, 2005 2:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
We have a dlq where most of the messages have a reason of 265.
I have been begging the local admins to put a dlqhandler on it to discard those as in fact the trigger did run and the queue is being serviced...
They have not gotten around to it yet.
As a result the dlq grows to the tune of 5 figures and any relevant message would be / is lost in the clutter.
I do not willingly take responsibility for such a qmgr...
So now you understand where I'm comming from.... |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Feb 11, 2005 2:28 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
@saper
Did you mean reason 2065?
If not, just out of curiosity what is Reason 265?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 11, 2005 2:49 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
MQFB_APPL_CANNOT_BE_STARTED = 265
But shouldn't you fix the problem of the TM tossing those errors, instead of discarding the messages that are telling you something is (was) wrong?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 11, 2005 8:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
I understand the local admin opened a PMR
but I have no idea what became of it.... 
Apparently not critical enough to warrant the time and attention.... |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Feb 12, 2005 8:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A 265 like that when the application starts up is not likely the fault of the trigger monitor.
It's likely that the application being run is doing something like returning a false error status after being run - instead of ending on a 0 condition, it's ending on something else.
So I epxect that IBM looked into it with the PMR, determined that the problem was not their fault, and the admin in question didn't follow up with the developer. Or the developer hasn't fixed the real problem yet.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
