camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marat Bedretdinov (JIRA)" <>
Subject [jira] Commented: (CAMEL-1461) A request route with a topic node incurs a 20 second wait and refers to the wrong MEP.
Date Sat, 04 Apr 2009 00:45:34 GMT


Marat Bedretdinov commented on CAMEL-1461:


I think your analysis is incorrect. The from(...:queue/topic....) route would only create
an INOUT Exchange if you've explicitly set a Message.replyTo field in the code that sent the
message into this queue/topic in the first place. So if you did that then it is expected that
the route will return a reply unless you explicitly set disableReplyTo=true in the from()
endpoint. The replyTo value would have still been propagated, just the runtime would not create
a consumer to expect a reply from the to() endpoint


I think the fact that the disableReplyTo=true does not mean that we need to reset the replyTo
or correlationID on the outgoing message in the producer that belongs to to(...) endpoint

The example shows a case in point:

from("amq-1:request").to("amq-2:request"); // route-1
from("amq-2:reply").to("amq-1:reply"); // route-2

so you can have:

app-1 -> amq-1:request -> amq2:request -> app-2 -> amq-2:reply -> amq1:reply
-> app-1

Here we have app-1 and app-2 have a conversion over two queues In fact if you want to do any
kind of transactional bridging this is the pattern you'd have to use. 

Also when one would want to use CamelTemplate to produce messages to a JMS broker with the
replyTo != null this change would reset replyTo = null unless explicitQosEnabled=true irrespective
of whether we're sending to a destination that is used in a one-way or a two-way route.

So I'd revert the change as I think the use case that this bug was filed under can be simply
resolved by using: from("...?disableReplyTo=true") and keeping the changes introduced changes
to the contract that can really be avoided.


> A request route with a topic node incurs a 20 second wait and refers to the wrong MEP.
> --------------------------------------------------------------------------------------
>                 Key: CAMEL-1461
>                 URL:
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-jms
>    Affects Versions: 1.6.0
>         Environment: ActiveMQ/Camel
>            Reporter: Michael Chen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0, 1.6.1
> If a route contains a node that publishes to a topic, the route is incorrectly suspended
for a default 20 seconds at the topic node.  Further, checks the MEP of the
original request Exchange and not the endpoint of the topic.
> For example, say I have a route built like this:
> {code}
> from("activemq:queue:request").
>   to("generate_news").
>   to("activemq:topic:news").
>   to("do_something_else");
> {code}
> The original request is expecting a reply. However, after the "news" is pumped into the
news topic, there is a default 20 second wait (requestTimeout).  This wait always results
in the exception: "The OUT message was not received within: 20000 millis on the exchange..."

> After reading the JmsProducer code, I changed the route to the following:
> {code}
> from("activemq:queue:request").
>   to("generate_news").
>   to("activemq:topic:news?exchangePattern=InOnly").
>   to("do_something_else");
> {code}
> This reveals the root of the bug, which is in the first few lines of method org.apache.camel.component.jms.JmsProducer.process(Exchange):
> {code}//
>     public void process(final Exchange exchange) {
>         final org.apache.camel.Message in = exchange.getIn();
>         if (exchange.getPattern().isOutCapable()) {
> {code}
> The above if statement checks the MEP of the original request's Exchange and not the
new endpoint of the news topic. This makes the above "?exchangePattern=InOnly" configuration
useless, because the original request MEP is InOut.  The result is that after that 20 second
time-out, the temporary queue for the original request has expired, so the whole request failed.
Note that the next node "do_something_else" is never reached due to the time-out exception.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message