Setting up an exception destination on the continuous queue

Body

In the past the question has come up often regarding the best way to configure the error queue exception destination for the inbound continuous queue (CQINBD) and the inbound continuous error queue (CQINBDERR) used by the Maximo Integration Framework.

There are many ways these exception destinations can be configured, and it really depends on how the Ingration Framework system is being used and what the preferred behavior would be.

In most previous documents, my instructions stated specifying the name of the error queue CQINBDERR in the exception destination property on the continuous inbound destination definition.  Then, on the error queue destination definition CQINDBERR, the value CQINBD is specified.

The two main reasons for this configuration are to prevent messages from becoming stuck on the continuous queue destination due to processing errors which can block other messages from being processed, and to prevent any performance degradation that would arise when a message in the continuous inbound queue fails processing into Maximo and is redelivered instantaneously repeatedly.  The latter results in an unresponsive JVM.

So why does setting the exception destination to CQINDBERR on the continuous queue destination prevent these problems?

There are two Message Driven Beans (MDBs) deployed with the Maximo application.  These message driven beans are defined in the EJB deployment descriptor files ejb-jar.xml and ibm-ejb-jar-bnd.xmi.  The first one is the continuous queue processor MDB for the inbound continuous queue, and the second is the continuous error queue processor MDB for messages that are moved to the exception destination after failing to be delivered successfully from the original continuous queue.  The main difference between these two MDB is that the continuous error queue MDB is bound to the error queue and contains logic to delay message delivery by 30 seconds between failures.  This delay prevents messages in the continuous error queue from causing performance issues because messages are only delivered once every 30 seconds.

However, there is another problem that can occur when using the error queue depending on how many messages are in the queue and how many endpoints you have available to the MDB.

In the default WebSphere configuration for the error queue, there are only 10 endpoints configured on the activation specification.  This can lead to problems where 10 message that have not been successfully delivered to Maximo for any reason can block other messages behind them from being processed at all.  To prevent this problem from occurring, specifying the original CQINDB queue destination as the exception destination for the CQINBDERR queue destination ensures that if the messages fail to deliver to Maximo they will be placed behind all other messages in the same queue.  This allows for the other messages on the queue destiation to receive their turn to be processed by the MDB so that no messages are blocked by other messages.  Note that setting the CQINBDERR exception destination value to itself (CQINDBERR) does not cause messages to be placed behind previously existing messages, instead placing them in front of other messages which causes those behind to appear stuck since they are not processed until the messges in front are either deleted or processed successfully into Maximo.

The MDB for the CQINDBERR queue has a redelivery delay of 30 seconds between message delivery attempts.  This feature was added to this MDB only, to prevent performance problems when messages are picked up by the MDB. 

Due to this preventative measure, the queues defined in Maximo should have a "Maximum Try Count" setting of 0.  Setting this to a value of 1 or higher can cause interferrence with the JMS message handling within WebSphere and should be avoided.

There are times when administrators may want to throw away the messages that fail to deliver to Maximo.  If an administrator is loading 1000's of records and is expected 100's to fail validation when being processed into Maximo and wish to ignore those messages, using the exception destination "System" is an acceptable alternative, however it must be noted that Maximo does not know these messages are routed to the System exception destination which caused them to remain within the Message Reprocessing application tables.  Therefore, in order to ensure Maximo is in sync with WebSphere, the administrator will need to truncate the database tables MAXINTERROR and MAXINTERRORMSG.  Additionally, the administrator will need to ensure that the System Exception Destination within WebSphere is regularily emptied and does not become full.

I hope the above clarifies some of the details about how the error queue is used in Maximo and look forward to any comments.