[
https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51022#action_51022
]
Marat Bedretdinov edited comment on CAMEL-1461 at 4/4/09 10:39 AM:
-------------------------------------------------------------------
Claus,
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.
was (Author: marat):
Claus,
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.
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.
