[
https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51030#action_51030
]
Marat Bedretdinov commented on CAMEL-1461:
------------------------------------------
Claus,
Yes I did manage to get all of the tests to pass before I restarted this
thread, but as you said my use case is now quite cumbersome and I think it
really does not have to be.
Please take a look at the patch attached. I think this will keep all happy.
I also show how the use case you described could be implemented. That is when
one wants to have a request/reply over a queue and then also send a message
(notification) over a topic and then collect correlated acknowledgement
message(s) that those notification have been received.
source app -> queue:request -> target app -> queue:reply -> source app
-> topic:notification
topic:notification -> notification subscriber app 1 -> queue:notificationAck
topic:notification -> notification subscriber app 2 -> queue:notificationAck
queue:notificationAck -> source app correlates ack using original request
correlationID or a unique selector
The usual use case for topics are one way messages, so if the user really wants
to reply to destination that came with a message received over a topic then the
receiver should be ready to accept more than one reply correlated on the same
source message. Since a request/reply pattern is 1 request 1 reply, then the
reply destination embedded in the message that came over a topic should really
be decoupled from the destination used to receive a reply from request/reply
pattern.
> 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
>
> Attachments: CAMEL-1461-2009-04-05-01-58.patch
>
>
> 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.
