[
https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51028#action_51028
]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
Marat,
Just a quick reply.
In your bridge scenario have you tried the *preserveMessageQos=true* in the to
destination?
That should keep the JMSReplyTo and JMSCorrelationID.
On a side note I do think there are two scenarios here that is difficult to
support out of the box without special configuration.
Just the most obvious should be the default one, that is IMHO the problem
Michael faced.
In your first example Camel will at (1) expect to return a reply, and that
reply is when the current exchanges ends, and it ends after step (4). So the
reply sent back is what the Exchange OUT message is after step (4) = what the
order service bean returns.
On the other hand, if you for instance at step (3) had a consumer on the other
side, that *also* sends a reply, then you end up with sending *x2* replies. To
prevent this you have to set the *disableReplyTo* on the from endpoint, so
Camel after step (4) does not return a reply, and the only reply is from the
"other side".
> So the point Michael made about JMS component honoring the contract of the
> 'to' endpoints is valid. We need to fix this so that if this is an inOnly MEP
> on the to() endpoint
> we won't be expecting a reply on the to() endpoint but will still propagate
> replyTo and correlationID values
We can only fix this in the JMS Producer to *not* listen for a reply. But the
problem is that if we also propagate JMSReplyTo/JMSCorrelationID then the
consumer does not know its an *inOnly* and this consumer can/will still send a
reply. If this consumer is also Camel then it will send a reply to the
JMSReplyTo, and thus we end up with the *x2* reply situation, even thought the
to was set with a {{pattern=InOnly}}. As I understand there are no MEP standard
for JMS, so we cannot propate the JMSReplyTo/JMSCorrelationID and then at the
same time tell the consumer, *not* to send a reply.
What do you think?
> 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.
