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 17:39:34 GMT


Marat Bedretdinov commented on CAMEL-1461:


I disagree. 

> The problem is that the replyTo is inherited from the very first from("activemq:queue:request")
when you send a replyTo JMS Message to it in the first place - then this replyTo is propagated
in the the route.

from() becomes an INOUT  *only* from the fact that the original message came with replyTo
!= null or you explicitly set a replyDestination as part of from() endpoint configuration.

The fact that the user choose to set the replyTo destination in the original message suggests
that one wants to receive a reply to its original message. If the designer of the Camel route
decided to drop this replyTo then he has to explicitly state that in the contract. Had Michael
done that he'd be all set. 

You want to make his live easier and not to require this flag. Fine. But you just broke the
old contract and now people that use CamleTemplate to send JMS messages with replyTo != null
will have to set explicitQoSEnabled=true on the from() endpoint they send messages to! You
will soon have people coming back and complaining about what I just described.

> And we dont want this replyTo propgated when you send to other JMS destinations, such
as the topic.

Why not? It is a very reasonable default to have the replyTo destination (topic or queue)
be relayed along the route as this was the message originator intention. You *could* plugin
a HeaderFilterStrategy and exclude headers you wish were not propagated (including replyTo
header). If HeaderFilterStrategy is not supported in JMS I'd rather fix this than keep the
changes comitted.

> What if the topic we sent to in the original sample is not based on Camel, then you cannot
disable reply to on this destination.

Why not? 

> What if the topic was a WebSphereMQ destination? 

If you have a cross broker message flow then you need to have alwaysCopyMessage=true as you
will not be able to send a AMQ message with replyTo != null to WebSphere with replyTo != null

This is already supported today. The replyTo will be resolved using WebSphere session.

I still recommend to revert the change.


> 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