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:
http://www.nabble.com/JMS-transactions-between-multiple-routes-tp25126004p25130955.html
Sent from the Camel - Users mailing list archive at Nabble.com.
