Skip to content

Detecting Repeatedly Redelivered Messages

In JMS 2.0, it is mandatory for JMS providers to set the JMSXDeliveryCount property, which allows an application that receive a message to determine how many times the message is redelivered.

If a message is being redelivered, it means that a previous attempt to deliver the message failed due to some reason. If a message is being redelivered multiple times, it can be because the message is bad in some way. When such a message is being redelivered over and over again, it wastes resources and prevents subsequent good messages from being processed.

When you work with WSO2 Micro Integrator, you can detect such repeatedly redelivered messages using the JMSXDeliveryCount property that is set in messages.

Being able to detect repeatedly redelivered messages is particularly useful because you can take necessary steps to handle such messages in a proper manner. For example, you can consume such a message and send it to a separate queue.

The following diagram illustrates how WSO2 Micro Integrator can be used to detect repeatedly redelivered messages, and store such messages in an internal message store.

To demonstrate the scenario illustrated above, let's configure the JMS inbound endpoint in WSO2 Micro Integrator using HornetQ as the message broker.

Synapse configuration

The synapse configuration for this example scenario is as follows:

<inboundEndpoint name="jms_inbound" onError="fault" protocol="jms"sequence="request" suspend="false">
    <parameters>
       <parameter name="interval">1000</parameter>
       <parameter name="transport.jms.Destination">queue/mySampleQueue</parameter>
       <parameter name="transport.jms.CacheLevel">1</parameter>
       <parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
       <parameter name="sequential">true</parameter>
       <parameter name="java.naming.factory.initial">org.jnp.interfaces.NamingContextFactory</parameter>
       <parameter name="java.naming.provider.url">jnp://localhost:1099</parameter>
       <parameter name="transport.jms.SessionAcknowledgement">AUTO_ACKNOWLEDGE</parameter>
       <parameter name="transport.jms.SessionTransacted">false</parameter>
    </parameters>
</inboundEndpoint>
<sequence name="request" onError="fault">
    <log level="full"/>
    <filter regex="1" source="get-property('default','jms.message.delivery.count')" xmlns:ns="http://org.apache.synapse/xsd">
        <then>
            <log>
                 <property name="DeliveryCounter" value="1"/>
            </log>
        </then>
         <else>
            <store messageStore="JMS-Redelivered-Store"/>
            <log>
                <property name="DeliveryCounter" value="more than 1"/>
            </log>
         </else>
    </filter>
    <drop/>
</sequence>
<registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
    <parameter name="cachableDuration">15000</parameter>
</registry>
<taskManager provider="org.wso2.carbon.mediation.ntask.NTaskTaskManager">
    <parameter name="cachableDuration">15000</parameter>
</taskManager>
<sequence name="main">
    <log level="full"/>
    <drop/>
</sequence>
<sequence name="fault">
    <log level="full">
        <property name="MESSAGE" value="Executing default &quot;fault&quot; sequence"/>
        <property expression="get-property('ERROR_CODE')" name="ERROR_CODE"/>
        <property expression="get-property('ERROR_MESSAGE')" name="ERROR_MESSAGE"/>
    </log>
    <drop/>
</sequence>
<messageStore name="JMS-Redelivered-Store"/>

See the descriptions of the above configurations:

Artifact Description
Inbound Endpoint This configuration creates an inbound endpoint to the JMS broker and has a simple sequence that logs the message status using the `JMSXDeliveryCount` value.
Task Manager The task manager configuration...
Registry Arfiact The registry artifact..
Top