JMS publish/subscribe pattern in ATG

The basic JMS publish/subscribe pattern leads to create an infinite number of same message executions.

The issue basically occurs when the  MessageConsumer is not able to successfully process the message.  When it occurs the transaction is rolled back and the message is put  back on the queue.   The  Subscriber  try to retries to process the message ,when this message has been put back in the Message Queue. The message will be successfully processed,if the error is result of a temporary condition. However, it is possible to create an infinite loop message executions,if the issue is as a result of invalid message. This will eventually leads to overwhelms the database with the large number of updates and rollbacks.

Recommendations:

1.     Use SQL JMS messages for all business critical operations .example: order or a customer profile updates.

2.     Limit the number of JMS message retries

3.     Limit the frequency of retries.

  .   Use error queue mechanizam

5.     Implement data validation on the MessageSource  components to prevent invalid message being put on the queue.

6.     Use consistent message configurations between the respective ATG layers.  Please refer to this http://myexperiencesinatg.blogspot.com/2014/10/preferred-atg-module-structure-for-any.html.

7.     Implement your custom code in transnational way which processes the messages.

    Difference between DMS or Patch Bay and SQL JMS

T   The ATG message system, or Dynamo Messaging System (DMS) or Patch Bay process the messages in synchronous way(also know as local DMS messages).  Critical JMS messages almost always use SQL JMS as the transport protocol.  The reason for this is that unlike local DMS messages, SQL JMS messages are persisted in the database.That means making the delivery of the messages more robust. Re delivery messages only works for SQL JMS destinations.

F    For each JMS input destination, Patch Bay or DMS starts a thread that continuously loops through a cycle of transaction begins, receiving a message from the destination, and calling the configured message sink, and ending the transaction. If Patch Bay attempts to deliver a message to a message sink and an error condition arises (any DB exceptions), the transaction is rolled back. The message remains in the destination, as if it were never delivered. Patch Bay tries to redeliver the message.

T    The configuration for the respective ATG JMS components is defined in the dynamoMessagingSystem.xml file.

     Sample code:

     

// NOTE: The purpose of the code is to handle JMS messages in transactional way.   // This is not tested or and will not compile. // p   public class MessageFilterSample extends GenericService implements MessageSource, MessageSink {     /*         JMS message receiver method (Subscriber in the Pub/Sub Pattern)     */     public void onMessage(String port, Message msg) throws JMSException {                   TransactionDemarcation td = new TransactionDemarcation();         try {                 td.begin(getTransactionManager(), TransactionDemarcation.REQUIRED);                     } catch (Exception e) {                 try {                         getTransactionManager().getTransaction().setRollbackOnly();                         //log error after rollback                 } catch (Exception e) {                         // log error                 }                 throw JMSException("JMS Exception");                     } finally {                 try {                         td.end();                 } catch (TransactionDemarcationException tde) {                         //log error in try catch block                 }           }               }     public void sendObjectMessage(Serializable pObjectMessage, String pType, String pPortName) throws JMSException {     } }