Maybe doing your processing in the scope of a transaction would be the way to go:
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.
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.
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)
This issue is currently in Apache Camel M1, hopefully it will go into the next fuse release.
CAMEL-1426 is included in the FUSE MR 1.6.0 release
There is a link to the release notes in the link above, where you can see the tickets fixed in this release.
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.