You can even use the correlation id to store the sequence number and make sure that the server application never performs a MQGET of a message out of sequence. This gives the server application the opportunity to detect when messages are out of sequence and either raise an alert, or wait until a message with correct sequence reaches the queue (re-submitted from dead-letter queue). Produce sequence numbers (1, 2, 3.) on the client applications. Challenge the pure FIFO nature of the application. To make sure that stopping the channel only affects this specific application.īefore reaching the last resort solution, consider alternatives: you have to use dedicated channels all the way from the client to server applications. you have to run on a dedicated queue manager, because removing the dead-letter queue is for the entire queue manager and not for a single channel. However there are cases where you absolutely need it (a dead-letter queue handler does not help because the whole architecture is asynchronous and you cannot be sure that the handler will resubmit message n before the application processes message n+1). I agree with Brandon that this should be the last resort solution. You can write a custom dead letter handler, and add as much processing logic as you wish in order to maintain your particular business requirements. The point is, you don't just "resubmit" messages from the dead letter queue if your particular architecture requires that messages are processed in sequence, etc. Once this happens, all your MQPUTs will simply start failing. Keep in mind also that when the channel stops and messages begin to pile up on the transmission queue, you can potentially fill it up. Yes, the channels stop, but isn't that bad enough? Especially if you are using clustering, and everything uses the same. My experience says that it is a dangerous path to go down, neglecting to have a dead letter queue. What additional monitoring needs to be done for channels, queue depths, etc? I am also partularly interested in what needs to be done to preserve the robustness of the MQ layer when a DLQ is not used. Does anyone have a cookbook or laundry list? I am particularly interested in finding out about the "gotcha's" of running without a DLQ. This last sentence is of particular interst to us because of the aforementioned Message Affinity and sequence requirements.ĭoes anyone have specific experience of running without a DLQ?Īre there any other issues that would result in DLQ's other than the queue full, non-existent queue or data conversions issues noted in the above quote? However, using dead-letter queues can affect the sequence in which messages are delivered, and so you may choose not to use them." If you do not, and the MCA is unable to put a message, it is left on the transmission queue and the channel is stopped.Īlso, if fast, non-persistent messages (see “Fast, nonpersistent messages” on page 22) cannot be delivered and no DLQ exists on the target system, these messages are discarded. We recommend that you define a dead-letter queue for each queue manager. Dead-letter queues are also used at the sending end of a channel, for data-conversion errors. Messages are put on this queue when they cannot be put on the destination queue for some reason (for example, because the queue does not exist, or because it is full). "The dead-letter queue (or undelivered-message queue) is the queue to which messages are sent if they cannot be routed to their correct destination.
#DEAD LETTER QUEUE MANUAL#
The MQ Intercommunication manual on page 13 also states: Messages are put on this queue if they cannot be delivered to their destination." "Each queue manager should have a dead-letter queue (also known as the undelivered message queue). The MQ Intercommunication manual on page 5 states:
For example, we cannot just take the DLQ's and resubmit them because this could result in those messages being processed out of sequence with respect to other messages that successfully processed after the DLQ's were written.
Obviously, this complicates our remediation process. Message Affinity and the sequence of messages is a requirement for us.īut sometimes we see messages being sent to the DLQ.
0 kommentar(er)
