[jira] Commented: (CAMEL-1461) A request route with a topic node incurs a 20 second wait and refers to the wrong MEP.

["Marat Bedretdinov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51018#action_51018 ] 

Marat Bedretdinov commented on CAMEL-1461:
------------------------------------------

Michael,

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

Claus, 

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.

Marat

> A request route with a topic node incurs a 20 second wait and refers to the wrong MEP.
> --------------------------------------------------------------------------------------
>
>                 Key: CAMEL-1461
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1461
>             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, JmsProducer.java 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.