I've been doing a little playing around with this problem today (and this week). I'm using a "purgatory" queue to get the "poison" out of the way temporarily. I go ahead and let the transactions rollback and put the message back on the queue, but I "blacklist" the message so that I know to send it to purgatory. I've got an example here:
https://github.com/jwcarman/smx-example/blob/master/camel/src/test/java/com/carmanconsulting/smx/example/camel/route/TestPurgatoryIdea.java I plan on adding in route auto-suspension, also. If a route sees too many things going to purgatory, then it can suspend itself (using a separate thread) and schedule a Timer task to come back and resume it at some later point (hopefully whatever was wrong is now fixed). Enjoy! On Thu, Jun 7, 2012 at 12:26 PM, James Carman <ja...@carmanconsulting.com> wrote: > Sorry, didn't see the rest of your message. Anyway, the problem > you're going to face here is that suppose you do some stuff (database > inserts, place messages on queues, etc.) between your input queue and > your web service. That "stuff" needs to get rolled back when you have > an issue and route your message to the DLC. If you tell Camel you've > "handled" the exception, the transaction doesn't rollback and your > message goes to DLC. So, you are sending your message to the > dead-letter channel where you may potentially replay it later and some > of the "stuff" that needs to go on during the processing of that > message has already taken place as a result of the committed > transaction. Therein lies the issue. > > On Thu, Jun 7, 2012 at 12:23 PM, James Carman > <ja...@carmanconsulting.com> wrote: >> Your transaction isn't rolling back if you "handle" the exception, is it? >> >> On Thu, Jun 7, 2012 at 12:21 PM, gramanero <graman...@gmail.com> wrote: >>> I have tested the case of using a route specific onException clause within a >>> transaction and it appears to work as I would expect (or hope). So I have a >>> route that is transactional and the final endpoint in the route throws an >>> exception I forced my restful service to just throw an exception). Without >>> the onException clause the message lands back in the queue as you would >>> expect due to it running within a transaction. With the onException clause, >>> I look for specific exceptions and if it is one of the exceptions that I >>> have specified I tell tell Camel that the exception has been "handled" (via >>> the handled clause) and I route the message to the dead letter queue, thus >>> moving the "bad message" out of the way of the messages remaining on the >>> queue. I think the key here is the use of the "handled" clause that tells >>> Camel that the message has been handled and therefore to NOT rollback the >>> transaction. The alternative choice is to tell Camel to "continue" on with >>> its normal processing which would have rolled back the transaction and put >>> the message back onto the queue (via the "continue" clause...at least I >>> think it is a clause). >>> >>> Hope that helps. >>> >>> -- >>> View this message in context: >>> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714139.html >>> Sent from the Camel - Users mailing list archive at Nabble.com.
