Comentários (2)

1 T.Robert comentou às Link permanente

The exception to this is when you specifically want the channel to stop for an undeliverable message. For example, in a B2B situation there is usually a gateway QMgr through which messages pass on the way to the internal WMQ network or cluster. On such a gateway, unrestricted routing of messages is not allowed - in other words, the inbound channel from the business partner is only authorized to an enumerated list of QRemote or QAlias definitions. It is NOT allowed to resolve messages by QMgr name and place them directly on a transmit queue. <br /> . <br /> For this setup, the queue names and resolution are all tested when it is placed into Production. The appearance of a message routed to something other than the authorized list of queues should only happen during a planned implementation. If it happens at any other time, there could be an unplanned change or some malicious activity. In this case it can be advantageous for several reasons to have the channel stop. <br /> . <br /> First, for a message in the DLQ it is sometimes difficult to tell the origin of the message. This is especially true in B2B situations where the name of the sending QMgr is not one of the well-known local QMgrs, and even more so when there are many B2B partners such as a clearing house type of operation. Stopping the channel positively identifies from where the mis-addressed message originated and it raises an alarm. (We assume all B2B gateways are monitored by an agent of some sort.) <br /> . <br /> Next, in the case of a malicious attack on the gateway there is no place to deliver the message locally so no COA or COD can be generated. A COA is always put with altuser authority and can be addressed to a queue that the sender does not normally have access to. <br /> . <br /> Finally, if the attack is malicious the sender can attampt to crash the QMgr by consuming all available disk space. There are a number of approaches to mitigate this including setting MAXMSGL on the inbound channel to something less than 4MB and setting the DLQ MAXDEPTH to a low value. For variable length XML payloads it may be difficult to find a value for MAXMSGL that provides much protection and insures all valid messages are processed. Setting a low MAXDEPTH allows for some messages to hit the DLQ but in a short time results in the same type of outage as if the DLQ were not present. Except now there are transactional, possibly high-value, messages stuck in the DMZ. Deleting the DLQ altogether insures that messages do not stack up on the gateway QMgr. <br /> . <br /> The B2B gateway scenario tends to generate exceptions to a number of WMQ rules of thumb. The presence of a DLQ on the B2B gateway needs to be evaluated in terms of security and availability and the right choice is often to NOT have a DLQ in this scenario.

2 RichardHamilton comentou às Link permanente

Hi T.Rob, <br /> Thanks for your comment.... you make a good point. <div>&nbsp;</div> I want to make sure our audience understands that I was documenting a "best practice" to help them avoid problems, and to minimize manual intervention. <div>&nbsp;</div> Regards, <br /> R J Hamilton <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div>