Message redelivery using GenericJMSRA

                                                                                              Author : Ramesh Parthasarathy



Redelivery is a feature in Generic JMS RA that can be used to resend ( try to resend ) the message to an MDB ( or any listener implementation) if there was an exception during the first send attempt. If the first invocation of the MDB's listener method throws an exception then the RA tries to redeliver it N ( number of redelivery attempts configured using the activation config property RedeliveryAttempts in inbound endpoint) times at an interval ( configured using activation property RedeliveryInterval). If redelivery is unsuccessful even after the attempts are exhausted the RA tries to send the message to a Dead Message Destination ( a JMS destination configured in the activation config). The redelivery happens entirely within the RA and is transparent to a message broker.
         This feature can compensate for the absence of a similar feature in an MQ provider. It is independent of the "Redelivery" feature that is available in most of the message brokers available in the market. The genericjmsra also gives the user an option of configuring a dead message destination to which the message would be sent if all the redelivery attempts failed. A DMD ( Dead Message Destination) has to be configured if the user does not want the MQ broker's redelivery capability to be utilised.


Successful redelivery

          Figure 1. Successful redelivery

Figure 1 shows a successful redelivery scenario. When the RA receives the message from the broker (Q1)  it tries to deliver it to the MDB. The MDB throws an exception and now the genericjmsra tries to redeliver the message. Redelivery is performed by the RA only if the message is transacted and the number of redelivery attempts is greater than 0. The GenericJMSRA waits for the duration of the redelivery interval before attempting another delivery to the MDB.  Redelivery continues until all the attempts are exhausted. In the figure above redelivery fails for the first time and then succeeds the next time.  This helps guard against any transient failures in the MDB.


DMD scenario


Figure 2: Redelivery failed - Successfuly sent message to DMD.



Figure 2 shows a scenario where all redelivery attempts fail. The RA would roll back the transaction if there were no DMD configured. If a DMD is configured then the message is sent to the dead message destination which typically is a queue or topic destination configured in the same/different broker. The DMD properties have to be configured using the activation spec config through the MDB deployment descriptors. The RA sends the message to the DMD destination configured using the destination name and the DMD connection factory properties. Please note that sending the message to the DMD is a best effort delivery. If the message is sent successfully then the transaction is committed and thus the message is removed from Q1. If the send to DMD fails (Figure 3) then the transaction is rolled back and the message is retained at Q1. This model ensures that there is absolutely no message loss.


Send to DMD failed

Figure 3: Redelivery failed - Send to DMD also failed.

Configuration :

       To leverage the redelivery feature, some minimal configuration is required in the MDB deployment descriptor. Redelivery and DMD information is supplied to the RA through the activation config properties.


Redelivery properties :

Snippet of sun-ejb-jar.xml :

          <activation-config-property>
            <activation-config-property-name>RedeliveryAttempts</activation-config-property-name>
            <activation-config-property-value>3</activation-config-property-value>
          </activation-config-property>
          <activation-config-property>
            <activation-config-property-name>RedeliveryInterval</activation-config-property-name>
            <activation-config-property-value>1</activation-config-property-value>
          </activation-config-property>

The redelivery attempts has to be more than 0. The interval is in seconds.



DeadMessageDestination properties:


                    <activation-config-property>
                        <activation-config-property-name>SendBadMessagesToDMD</activation-config-property-name>
                        <activation-config-property-value>true</activation-config-property-value>
                    </activation-config-property>  
                    <activation-config-property>
                        <activation-config-property-name>DeadMessageDestinationType</activation-config-property-name>
                        <activation-config-property-value>javax.jms.Queue</activation-config-property-value>                       
                    </activation-config-property>  
                    <activation-config-property>
                        <activation-config-property-name>DeadMessageDestinationProperties</activation-config-property-name>
                        <activation-config-property-value>imqDestinationName=dmdqueue</activation-config-property-value>
                    </activation-config-property>  
                    <activation-config-property>
                        <activation-config-property-name>DeadMessageConnectionFactoryProperties</activation-config-property-name>
                        <activation-config-property-value>imqAddressList=mq://localhost:2222</activation-config-property-value>
                    </activation-config-property>



The above values are for a JavaBean integration mode.  Above properties tell the RA that the dead message destination is a Queue destination with name dmdqueue and is provided by the broker located in the imqAddressList.

For other properties that are relevant to DMD configuration please refer to the generic JMS RA user guide.


Some scenarios/test cases :

General Setup : MDB listening to a queue "inqueue" (present in a broker "inbroker") and sends message to queue  "outqueue" (present in a broker "outbroker"), the inbroker and outbroker can be present in same /different machines.


1.No redelivery test:

Redelivery enabled : attempts is 3 and interval is 1 second. The first delivery succeeds , so redelivery need not happen.

a. Transaction logs in both inbound and outbound brokers should be clean.
b. There is 1 message in outqueue and 0 messages in inqueue ( none of them held in transaction).
c. No messages in DMD ( does not matter if DMD is configured or not for this test).


2. Successful redelivery test:

Redelivery enabled : attempts is 3 and interval is 1 second. The first delivery fails, and the redelivery succeeds on the first redelivery attempt. Similar to Figure 1.

a. Transaction logs in both inbound and outbound brokers should be clean,
b. There is 1 message in outqueue and 0 messages in inqueue
c. No messages in DMD ( does not matter if DMD is configured or not for this test).



3. Failed Redelivery

Redelivery enabled : attempts is 3 and interval is 1 second. DMD is not configured , (SendDeadMessageToDMD is false). In this test all the delivery attempts to MDB should fail, make the MDB throw runtime exception for all requests. Since all attempts for delivery fails, the RA tries to send message to DMD, and since DMD is not configured the message should remain in the inqueue.

a. Inbroker TX logs shows one transaction in STARTED state, no entries in outbroker TX logs.
b. There is 1 message in the inqueue and should not be held in transaction, no messages in outqueue.
c. No messages in DMD.


4. Failed redelivery - Wrong DMD destination information.

Redelivery enabled : attempts is 3 and interval is 1 second. DMD is configured , (SendDeadMessageToDMD is true) and DMD connection factory information is invalid.

In this scenario all the delivery attempts to MDB should fail, make sure the MDB throw runtime exception for all requests. Since all attempts for delivery fails, the RA tries to send message to DMD, and since DMD is not configured the message should remain in the inqueue.

a. Inbroker TX logs shows one transaction in STARTED, no entries in outbroker TX logs
b. There is 1 message in the inqueue and should not be held in transaction, no messages in outqueue.
c. No messages in DMD.


5. Failed redelivery - Delivered successfully to DMD.

Redelivery enabled : attempts is 3 and interval is 1 second. DMD is configured , (SendDeadMessageToDMD is true) and DMD connection factory information is valid and DMD destination is valid

In this test all the delivery attempts to MDB should fail, make the MDB throw runtime exception for all requests.
Since all attempts for delivery fails, the RA tries to send message to DMD, and since DMD is not configured the message should remain in the inqueue.


a. No entries in outbroker TX logs of both brokers.
b. There is 0 message in the inqueue and should not be held in transaction, no messages in outqueue.
c. 1 messages in DMD.


6. Redelivery not configured, but DMD is configured.

Redelivery disabled, DMD is configured properly with correct CF and destination.

The message delivery to MDB should fail , throw a runtime exception, no redelivery so the message should be retained in broker if its transacted (supportsXA=true)

a. Message is delivered to DMD , 1 message in DMD destination.
b. 0 messages in inqueue with no transactions.
c. 0 messages in outqueue, no transactions pending.


Terms of Use; Privacy Policy; Copyright ©2013-2017 (revision 20160708.bf2ac18)
 
 
Close
loading
Please Confirm
Close