[
https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51024#action_51024
]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
>> 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.
Agree
> 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.
That is what he is in fact trying to do. He want to return a reply but at the
same time send a fire and forget message to a topic. To send this "fire and
forget" message he should use either:
- wireTap
- inOnly
- to with pattern=InOnly
The problem is that when he does that Camel will propagate the original JMS
headers along, and then Camel itself sees that there is a JMSReplyTo and
therefore it want to wait as well.
The original exchange will still be InOut and Camel will send a reply back. Its
the _fire and forget_ JMS message that is the problem. This cannot be cleanup
done out of the box with Camel if we revert the change, then you need to add
clear all the JMS headers with a custom HeaderFilterStategy or whatever. This
is not very easy. The route explicit states that its a _fire and forget_ and
thus there should be *no* JMSReplyTo send.
The HeaderFilterStategy is a kinda advanced feature where you need to plug it
in and add your own java implementation. This is not desired for doing a very
common route such as spin off a _fire and forget_ while doing a JMS
request/reply.
> But you just broke the old contract and now people that use CamleTemplate to
> send JMS messages with replyTo not 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.
What do you mean? If the use CamelTemplate and send a request/reply (eg
requestXXX) then its an InOut and then the from endpoint should not have any
special options.
For instance in the code below:
{code}
from("activemq:queue:foo).to("bean:bye");
String out = template.requestBody("activemq:queue:foo", "Hello", String.class);
{code}
Assuming the {{bye}} bean returns a response such as: {{ return "Bye World" }}
then the {{out}} String will contain the value returned = {{Bye World}}.
The method {{requestBody}} is used for *InOut* MEP and thus Camel will set a
{{JMSReplyTo}} when it send the {{Hello}} message to the JMS foo queue. And
when Camel receives this message it sees the JMSReplyTo and returns the
response.
The contract is *not* broken.
>> 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?
Why should Camel send a JMSReplyTo to a MQ destination in the first place where
we *do not* want a reply? Lets imagine the MQ destination is part of a
production system you cannot change.
So what if it inspects this JMSReplyTo and want to send a reply that it was
*never* intended to send. It was after all just a _fire and forget_ message
that was send to it.
> 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.
