Deadletter / Redelivery

[ee7arh]

Hi,

I have various routes setup and on each I define an errorHandler / redelivery policy

In my application, if something fails and is retried x-times and still fails, it will go to the deadLetter channel. This is fine, but what if I want to re-queue or re-run my request through the system manually later.... all the way from the top?

My issue is that if I have routes which route a messages from/to various beans. These beans might take in the message as a String and pass it on as an Object (i.e. they transform the message). So at the end of the route, the message is totally different to what it was at the start of the route.

If half way through the route propogation, the delivery fails, what ends up on the deadLetter channel is the message as it was before it was processed by the node which failed. Therefore I cannot re-run this message "from the top" as it is partially transformed/processed.

I wonder what my options are. If I could somehow figure out at which node it failed, perhaps I could manually re-queue the message to the correct bean. Or is there a way to log the original message at top of the route? Or perhaps I should use Spring bean propagation)

Any ideas / design strategies would be appreciated

Thanks

Andrew

[stlewis]

Hey Andrew,

Maybe doing your processing in the scope of a transaction would be the way to go:

http://camel.apache.org/transactional-client.html

At least if there's a problem the transaction is rolled back and you should wind up with the original message going to the dead letter queue.

[davsclaus]

Interesting thought.

The transactional client EIP pattern is really about a "all or nothing" so that will do what you want but not all transports support transactions.

You can safe a copy of your incoming messages so when you need to do a redelivery from the top you can read from the copy.

In my experience its often required to store copies of all incoming data in some store in case of dispute or for auditing etc. What I have often did was to build a manual redeliver feature so you could drop a incoming file in a special folder.

But back to the thought of using the original exchange in the DLQ, instead of current snapshot that failed. That is interesting feature to add to Camel. So you could configure the DLC whether it should use original incoming message or the current failed message.

[ee7arh]

Thanks for replies and suggestions,

I guess in my case Spring Transaction is the way to go since I use JMS as th main transport. I only have the problem at moment is that all my routes are defined in DSL and there is no  tag just yet in fuse (I start my app from Spring)

See: http://issues.apache.org/activemq/browse/CAMEL-1426

This issue is currently in Apache Camel M1, hopefully it will go into the next fuse release.

BRegards

Andrew

[davsclaus]

CAMEL-1426 is included in the FUSE MR 1.6.0 release

http://fusesource.com/forums/ann.jspa?annID=61

There is a link to the release notes in the link above, where you can see the tickets fixed in this release.

[davsclaus]

Hi

Just an updated on this one.

I have added the feature to be able to use the original exchange when moved to a dead letter queue.

CAMEL-1600 is the ticket tracking this feature.

Wiki pages at Apache have also been updated.

The feature exists on both deadLetterChannel and onException.