camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gramanero <graman...@gmail.com>
Subject Re: Transacted vs DeadLetterQueue
Date Fri, 08 Jun 2012 12:07:52 GMT
Perhaps you are correct in that the onException gets fired within the
bounds of the transaction thus making the operation, as a whole, atomic.
However, and keep in mind that I am still learning Camel, from what I can
tell the onException fires within the bounds of the transaction and the
<handled><constant>true</constant></handled> elements are basically
telling
Camle that "everything is ok" which means that things do not get rolled
back. In my case, I am trying to catch specific exceptions that are thrown
from the restulful service (which means that no work happened...i.e. no DB
updates or anything), and push the message onto the DLQ to get it out of
the way. Essentially saying that those messages are bad and I don't/can't
process them.

If I let the transaction rollback, then I have the message on the queue
still and then run the risk of trying to process it a second time which
will result in the same scenario and most likely end up in an endless loop.
Unless I configure the redelivery policy to only attempt to redeliver N
times as opposed to an infinite numer of times.
On Fri, Jun 8, 2012 at 7:30 AM, James Carman-2 [via Camel] <
ml-node+s465427n5714184h80@n5.nabble.com> wrote:

> You want it to be atomic with the get from the input queue don't you?  It
> would make sense to me.
> On Jun 8, 2012 7:13 AM, "gramanero" <[hidden email]<http://user/SendEmail.jtp?type=node&node=5714184&i=0>>
> wrote:
>
> > Now that you mention it, one might think that, but that does not appear
> to
> > be the case. With the DLQ put in the onException clause, the DLQ put
> does
> > not rollback. I think that is where the Handled clause comes into play.
> >
> > On Fri, Jun 8, 2012 at 7:10 AM, James Carman-2 [via Camel] <
> > [hidden email] <http://user/SendEmail.jtp?type=node&node=5714184&i=1>>
> wrote:
> >
> > > Won't the dlc "put" be in the transaction too?  That would rollback
> too,
> > > thus nothing ever happened.
> > > On Jun 8, 2012 6:56 AM, "James Carman" <[hidden email]<
> > http://user/SendEmail.jtp?type=node&node=5714181&i=0>>
> > > wrote:
> > >
> > > > Try it with client cache control.  Take a look at my example.
> > > >
> > > > On Fri, Jun 8, 2012 at 6:47 AM, gramanero <[hidden email]<
> > http://user/SendEmail.jtp?type=node&node=5714181&i=1>>
> > > wrote:
> > > > > No, it is not rolling back if you use the Handles element with a
> > > > constant value of true. If you use the Continue element then I
> believe
> > > it
> > > > will roll back.
> > > > >
> > > > > Sent from my iPod
> > > > >
> > > > > On Jun 7, 2012, at 11:46 PM, "James Carman [via Camel]" <
> > > > [hidden email] <http://user/SendEmail.jtp?type=node&node=5714181&i=2>>
>
> > > wrote:
> > > > >
> > > > >> Your transaction isn't rolling back if you "handle" the
> exception,
> > is
> > > > it?
> > > > >>
> > > > >> On Thu, Jun 7, 2012 at 12:21 PM, gramanero <[hidden email]>
> 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.
> > > > >>
> > > > >>
> > > > >> If you reply to this email, your message will be added to the
> > > > discussion below:
> > > > >>
> > > >
> > >
> >
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714151.html
> > > > >> To unsubscribe from Transacted vs DeadLetterQueue, click here.
> > > > >> NAML
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > >
> > >
> >
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714179.html
> > > > > Sent from the Camel - Users mailing list archive at Nabble.com.
> > > >
> > >
> > >
> > > ------------------------------
> > >  If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714181.html
> > >  To unsubscribe from Transacted vs DeadLetterQueue, click here<
> >
> >
> > > .
> > > NAML<
> >
> http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>
> > >
> > >
> >
> >
> > --
> > View this message in context:
> >
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714182.html
>
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714184.html
>  To unsubscribe from Transacted vs DeadLetterQueue, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5713992&code=Z3JhbWFuZXJvQGdtYWlsLmNvbXw1NzEzOTkyfC0xNjAyMDYxMDQz>
> .
> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714194.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message