camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: Transacted vs DeadLetterQueue
Date Thu, 07 Jun 2012 22:23:57 GMT
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:

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).


On Thu, Jun 7, 2012 at 12:26 PM, James Carman
<> 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
> <> wrote:
>> Your transaction isn't rolling back if you "handle" the exception, is it?
>> On Thu, Jun 7, 2012 at 12:21 PM, gramanero <> 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" least I
>>> think it is a clause).
>>> Hope that helps.
>>> --
>>> View this message in context:
>>> Sent from the Camel - Users mailing list archive at

View raw message