Exception handling and move original handling to an error queue

[Joacim J]

Hi there,

I am testing some exception scenarios and want to roll back the original IN message to a error queue but cannot get it to work. I tried to add parts of this to SOI Toolkit custom

http://www.mulesoft.org/documentation-3.2/display/32X/Exception+Strategy+Most+Common+Use+Cases#ExceptionStrategyMostCommonUseCases-Routethemessage%28initsinitialstate%2Cwhenittriggeredtheflow%29tothedeadletterqueue so it currently looks like:

        <custom-exception-strategy class="org.soitoolkit.commons.mule.error.ServiceExceptionStrategy">  

<commit-transaction exception-pattern="*"/> <!-- [2] -->

<processor-chain>

            <expression-transformer evaluator="header"  expression="SESSION:originalMessage"/>  <!-- [3] -->

            <message-properties-transformer scope="session">  <!-- [4] -->

                <delete-message-property key="originalMessage"/>

            </message-properties-transformer>

            <jms:outbound-endpoint  connector-ref="soitoolkit-jms-xa-connector" queue="error.queue">  <!-- [5] -->

                <jms:transaction action="ALWAYS_JOIN" />

            </jms:outbound-endpoint>

        </processor-chain>

    </custom-exception-strategy>

But doesn't work.

Any hints on how shall this type of exception handing be implemented with SOI Toolkit ?

Regards

Joacim

[Magnus Larsson]

Hello Joakim!

 

If you generate a one-way jms to jms service you will get sample code (and integration tests) that retries the processing and moves to a DLQ after a number of retries.

It is based on rather old error handling constructs in Mule but it should work.

The one-way-robust generator use more recent error handling constructs in Mule but it is also a bit more involved.

Try both and let us know what you think!

We are preparing a new set of generators adopted for Mule 3.5, hope to see an initial milestone-release in the coming weeks. It should also be of interest to take a look into.

Best Regards,

Magnus.

--
You received this message because you are subscribed to the Google Groups "soi-toolkit-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to soi-toolkit-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joacim J]

Hi Magnus,

I am scratching my head :)

Generated both one-way JMS-JMS and one-way robust VM-VM.

Executed it in three ways

Test 1

Running JUnit tests I get success but difficult to see the DLQ queue etc:)

Test 2

Running generated MuleServer in /src/test/java, it starts and creates IN/OUT queues. 

Sending an invalid message (starting with "C"), so a TransformerException is thrown 4 times and message rollback 3 times (the fourth time it should go to DLQ). But no DLQ is created and no messages there of course and the IN message is committed. 

Same behavior if I trigger a RuntimeException in the transformer.

Test 3

Running as Mule Application, same behavior as in Test 2.

Using MuleESB 3.4.0 Community Edition with source generated for that environment.

Hmmm, strange...need to analyze :)

Regards

Joacim

[Håkan Dahl]

Joakim,

there are some gotchas with ActiveMQ DLQ-handling:

1. Make sure you are sending persistent messages if you want them to end up on a DLQ using default AMQ config. Non-persistent messages are discarded instead of put on a DLQ.

See: http://activemq.apache.org/message-redelivery-and-dlq-handling.html

Note: if you are sending messages using the AMQ webconsole, there is a checkbox for "Persistent Delivery" that you should tick.

2. If you haven't configured a deadletter-strategy for your AMQ-broker, all DLQ-messages will end up on queue ActiveMQ.DLQ - which might not be obvious.

With a deadletter strategy you can configure messages to end up on a queue named like the inbound queue with either prefix or suffix like "DLQ".

Cheers,

/håkan

[Magnus Larsson]

Hello again Joakim!

To complement Håkans answer please look into the generated integration test for the jms-to-jms one way case!

There you will find notes such as:

    /**

     *

     * DLQ tests expects the following setup in activemq.xml (in the <policyEntry> - element):

     *                   <deadLetterStrategy>

     *                     <!--

     *                      Use the prefix 'DLQ.' for the destination name, and make

     *                      the DLQ a queue rather than a topic

     *                     -->

     *                     <individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true" />

     *                   </deadLetterStrategy>

     * 

     */

    public JmsToJmsIntegrationTest() {

...and tests that verify that the DLQ is receiving poisoned messages as expected:

    @Test

    public void testJmsToJms_transformationError() throws JMSException {

        .

        .

        .

        // Verify that the message now is gone from the in-queue

        assertEquals("Sent message not removed", 0, jmsUtil.browseMessagesOnQueue(IN_QUEUE).size());

        // Verify that the in-message now is found on the deadletter queue

        List<Message> msgs = jmsUtil.browseMessagesOnQueue(DEADLETTER_QUEUE);

        assertEquals("Incorrect number of DLQ-messages", 1, msgs.size());

        String dlqMsg = ((TextMessage)msgs.get(0)).getText();

        assertEquals("Message on DLQ is not identical with the message sent", dlqMsg, message);

        // Verifying that we now have four identical log-messages on the error-log-queue

        // One message for the initial attempt and three more for the redeliveries

        assertErrorLogMessages(4, expectedErrMsg);

        // Verify as well that nothing is placed on the out-queue

        assertEquals("Unexpected message on out-queue", 0, jmsUtil.browseMessagesOnQueue(OUT_QUEUE).size());

If these tests runs ok it indicates to me that we have the expected behaviour when running the integration test (using an embedded activemq broker)

If you runt the flow in a mule-server and have configured AMQ as defined above you should be able to see the same behaviour if you place a (persist) poisoned message in the in-queue!

Try it out and let us know if it still doesn't seem to work!

Regards,

Magnus.

[Joacim J]

Hi Håkan and Magnus,

Yes, it works as you explain and I have gained some new knowledge in ActiveMQ/MuleESB :) I somewhat expected that I was missing some parts of the platform...since it's different from what we have at work (WMQ/WMB) and also different usage e.g. we are not using DLQ for the same type of errors and instead have ERROR queues for message failures in ESB instead of relying on WMQ's DLQ handling. 

I also made a test with Mule exception handling to move the original IN message to some queue in case as described here but I feel a bit strange that Mule have the example of just sending the payload (without headers) and I want the full original message.

Thanks for your help and now I need to do some real implementation @ home since I have >20.000 subscribed events from my home automation system (and integrated wireless sensor network) on AMQ (sent with MQTT).

Cheers

Joacim

[Joacim J]

EDIT:

I also made a test with Mule exception handling to move the original IN message to some queue in case as described here but I feel a bit strange that Mule have the example of just sending the payload (without headers) and I want the full original message.

Made a little test more and it seems to include e.g. ReplyTo header but not Correlation ID. Anyway, that is another topic :)

/ Joacim

[Magnus Larsson]

Hello again!

Great!

Yes, that's true. We are relying on the infrastructure to remove poison messages and put them on various DLQ queues.

When we talk about an error-queue we are talking about the queue that holds the error-messages related to the processing of the poison messages (or other failed processing) so we have a naming missmatch compared to the environment you are used to.

Note: MQTT we like :-)

Regards,

Magnus.