camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya S <>
Subject Re: JMS transactions between multiple routes
Date Tue, 25 Aug 2009 15:43:30 GMT
Hi Fintan,

I basically took Camel spring example from 1.6.1
(apache-camel-1.6.1\examples\camel-example-spring-jms) and modified
I would like camel to propagate my exception (or jms fault) that
happen in some nested route up to the original producer(client). I
thought I can do this with transactions.

My producer code looks like this:
        // get the camel template for Spring template style sending of
messages (= producer)
        ProducerTemplate<Exchange> camelTemplate =
(ProducerTemplate<Exchange>) context.getBean("camelTemplate");

        System.out.println("Invoking the multiply with 22");

        Exchange exch = null;
        try {
        	exch = camelTemplate.send("jms:queue:numbers", new Processor(){
				public void process(Exchange exchange) throws Exception {
					Message in = exchange.getIn();
	        int response =
ExchangePattern.InOut, 22);

So, yes, it is InOut.

The multiplier endpoint simply multiplies the body by 3, and puts the
result into exchange.
However, the execution should not get to the multiplier, since the
very first thing I do in Route 2 is to throw an exception:

Route 2:
       .process(new Processor() {
                       public void process(Exchange arg0) throws Exception {
                               throw new Exception("Hello World Exception");


I was hoping this exception will be propagated up to my producer.
However, by default, with deadLetterQueue, the exception does not seem
to be propageted.
I thought this could be done with transactional error handler, and
that's why I'm trying to understand how it works.
Please, let me know what is the right way to do this?


On Tue, Aug 25, 2009 at 2:14 AM, Fintan Bolton<> wrote:
> Hi Ilya,
> That's an interesting routing example. I have a couple of observations about
> your routes, based on my understanding of Camel transactions (which is by no
> means perfect!).
> Route 1:
>        from("jms:queue:numbers")
>        .policy(pp)
>        .to("jms:queue:mybadqueue?transactedInOut=true")
>        .to("multiplier");
> I believe that the call, policy(pp), in this route is unnecessary. The
> transaction has already been kicked off by the jms:queue:numbers endpoint,
> so there is no need to start it again. What policy(pp) actually does (where
> pp represents the PROPAGATION_REQUIRED policy) is to check whether a
> transaction has already started on this thread. It has, so policy(pp) does
> nothing.
> I suspect that the transactedInOut setting is ignored in this context. My
> understanding is that the options, transacted and transactedInOut, apply
> only to consumer endpoints, not producer endpoints. Or, if transactedInOut
> is not being ignored, perhaps it is causing some unexpected behavior?
> A key point about the two routes in your example is that each of the routes
> are processed in separate transactions. A message will not be available to
> pull from the mybadqueue queue (Route 2) until the transaction in Route 1
> has committed. So, if you are not seeing any messages in mybadqueue, that
> implies that the transaction in Route 1 has not committed.
> Perhaps some part of Route 1 is hanging, thus preventing a commit? Could you
> clarify a couple of points:
> 1. Do the incoming messages (from jms:queue:numbers) have their JMS ReplyTo
> header set? As Claus says, if you are processing InOut exchanges, this is a
> special case.
> 2. What does the multiplier endpoint do? Could it be hanging (thus
> preventing a commit)?
> 3. What happens when you remove the transactedInOut="true" setting? I
> suspect that this setting is incorrect and might cause problems.
> -
> Cheers,
> Fintan
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

View raw message