| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Publish and DEAD.LETTER.QUEUE |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Wed Oct 17, 2007 2:56 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
Coming back to your NOTAM... and yes I know how critical they are (watch the Jag episode with the Italian lady pilot and the chopper incident ...)
What is even more critical here is that due to the fact that the receiving system is not picking up it's messages you are jeopardizing the broker and thus all receiving systems....
So you do need a DLQ.
Once the problem is solved move all messages from the DLQ back to their original destq. The receiving app should put all messages into a DB with their timestamps as stated by the internal timestamp ref on the NOTAM not by the timestamp ref on the message's MQMD. It should also have a thread identification on the NOTAM so as to have a timeline for a specific notification topic....
Now when the receiving office has fixed it's problem (during which it could not receive any NOTAM at which point the receiving office needs to fall back to a different system...) there will be a little delay until the receiving queue is again empty... This is when the office gets caught up in the NOTAMS reading those redelivered from the DLQ...
So message affinity here is bad. Better way is post to a DB and let the DB select determine threads and timeline... Have it also store the timestamp of reception of the NOTAM and the timestamp in the MQMD. This will help investigate the problems when they occur... 
So in the DB you have 3 timestamps
- Timestamp of NOTAM issue (internal to notam message)
- Timestamp NOTAM was received to DB
- Timestamp on NOTAM's message's MQMD
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| banjar1 |
| Posted: Wed Nov 21, 2007 2:25 am Post subject: |
|
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
So far I got this:
I passed PMR 66041,999,724 to the L3 team for review. Here is
their update:
First let me try to clarify how the broker is intended to behave in the
situation where a persistent message cannot be delivered to one or more
subscriber queues, where no dead letter queue exists, and where the
broker is not permitted to discard the publication.
When the brokers MQPUT to the subscriber queue fails in these conditions
then the unit of work (UOW) used to process this publish request will be
backed out. The publish thread will suspend for 5 seconds and then retry
the operation, after 5 unsucessful attempts to publish then the stream
will end and will be restarted after increasing intervals to retry the
operation.
The net effect of this processing ought to be that this failing
publication is retried at progressively longer time intervals
(once the interval reaches 300 seconds it doesn't get any longer).
.
Note that as long as this 'poison' publish mesage is in this state then
no other publish requests will be processed by the stream. This does
guarantee the ordering for messages published on each stream, but at
the cost of effectively inhibiting publications during such a condition.
.
There does appear to be a problem in this processing, in that once
the initial 5 retries have been attemptd then the messages backout count
reaches 5. The broker is checking the BackoutCount before the first
retry attempt after the stream has been restarted, and thus each time
the stream is restarted it immediately detects a 'poison' message and
ends without retrying the publish.
.
Please raise an APAR so that this processing can be improved so that
upon stream restart then we will attempt to process the first message
on the stream queue regardless of that messages BackoutCount.
<---end--->
I created APAR IZ08754 to address this and returned the PMR to the
L3 team to fix this problem. Once the APAR is closed, we will see
if they can build an ifix. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 21, 2007 6:17 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
banjar1, thanks for taking the time to post this. Good to know we all weren't missing something obvious and that it was a bug.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
