You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Michael Chen (JIRA)" <ji...@apache.org> on 2009/03/16 19:16:39 UTC
[jira] Created: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
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
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.
[jira] Issue Comment Edited: (CAMEL-1461) A request route with a
topic node incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50772#action_50772 ]
Claus Ibsen edited comment on CAMEL-1461 at 3/26/09 5:59 AM:
-------------------------------------------------------------
Fixed now. The disableReplyTo is now not needed.
trunk: r757693, 757730, 758617
1.x: 757728
was (Author: davsclaus):
Fixed now. The disableReplyTo is now not needed.
trunk: r757693, 757730
1.x: 757728
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50770#action_50770 ]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
This one works:
{code}
from("activemq:queue:inbox")
.to("mock:inbox")
.inOnly("activemq:topic:order")
.beanRef("orderService", "handleOrder");
from("activemq:topic:order?disableReplyTo=true")
.to("mock:topic");
{code}
I will work on the ((disableReplyTo=true}} so it is not needed to be specified.
> 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
>
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (CAMEL-1461) A request route with a
topic node incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50770#action_50770 ]
Claus Ibsen edited comment on CAMEL-1461 at 3/24/09 4:18 AM:
-------------------------------------------------------------
This one works:
{code}
from("activemq:queue:inbox")
.to("mock:inbox")
.inOnly("activemq:topic:order")
.beanRef("orderService", "handleOrder");
from("activemq:topic:order?disableReplyTo=true")
.to("mock:topic");
{code}
I will work on the {{disableReplyTo=true}} so it is not needed to be specified.
was (Author: davsclaus):
This one works:
{code}
from("activemq:queue:inbox")
.to("mock:inbox")
.inOnly("activemq:topic:order")
.beanRef("orderService", "handleOrder");
from("activemq:topic:order?disableReplyTo=true")
.to("mock:topic");
{code}
I will work on the ((disableReplyTo=true}} so it is not needed to be specified.
> 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.
[jira] Resolved: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-1461.
--------------------------------
Resolution: Fixed
Fixed now. The disableReplyTo is now not needed.
trunk: r757693, 757730
1.x: 757728
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51019#action_51019 ]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
@Marat,
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.
And we dont want this replyTo propgated when you send to other JMS destinations, such as the topic.
The changes introduces check the MEP contract. If the MEP is *not* out capable then it wont set a {{JMSReplyTo}} on the {{javax.jms.Message}} object when Camel sends it.
This is more correct than ignoring this fact, its very common to route messages with Camel using JMS and send it to other JMS destinations during the routing.
Remembering to add {{jmsDisableReplyTo=true}} is a pity workaround IMHO and many end users will face same problem as Michael and wont find the solution immediately. The JMS component has too many options and its hard to know which options to use for what. Maybe splitting the table into commonly used, rarely used and advanced only would help out.
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51022#action_51022 ]
Marat Bedretdinov commented on CAMEL-1461:
------------------------------------------
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.
[jira] Updated: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marat Bedretdinov updated CAMEL-1461:
-------------------------------------
Attachment: CAMEL-1461-2009-04-05-01-58.patch
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51051#action_51051 ]
Marat Bedretdinov commented on CAMEL-1461:
------------------------------------------
Claus,
Thanks for applying the patch. Yes I was aware that I could work around the change made, but with the patch you just applied no changes will be required either to my tests/demos and Michael will still be happy.
Cheers,
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
>
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-1461:
----------------------------------
Assignee: Claus Ibsen
> 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
>
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51018#action_51018 ]
Marat Bedretdinov commented on CAMEL-1461:
------------------------------------------
Michael,
I think your analysis is incorrect. The from(...:queue/topic....) route would only create an INOUT Exchange if you've explicitly set a Message.replyTo field in the code that sent the message into this queue/topic in the first place. So if you did that then it is expected that the route will return a reply unless you explicitly set disableReplyTo=true in the from() endpoint. The replyTo value would have still been propagated, just the runtime would not create a consumer to expect a reply from the to() endpoint
Claus,
I think the fact that the disableReplyTo=true does not mean that we need to reset the replyTo or correlationID on the outgoing message in the producer that belongs to to(...) endpoint
The example shows a case in point:
from("amq-1:request").to("amq-2:request"); // route-1
from("amq-2:reply").to("amq-1:reply"); // route-2
so you can have:
app-1 -> amq-1:request -> amq2:request -> app-2 -> amq-2:reply -> amq1:reply -> app-1
Here we have app-1 and app-2 have a conversion over two queues In fact if you want to do any kind of transactional bridging this is the pattern you'd have to use.
Also when one would want to use CamelTemplate to produce messages to a JMS broker with the replyTo != null this change would reset replyTo = null unless explicitQosEnabled=true irrespective of whether we're sending to a destination that is used in a one-way or a two-way route.
So I'd revert the change as I think the use case that this bug was filed under can be simply resolved by using: from("...?disableReplyTo=true") and keeping the changes introduced changes to the contract that can really be avoided.
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.
[jira] Issue Comment Edited: (CAMEL-1461) A request route with a
topic node incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50772#action_50772 ]
Claus Ibsen edited comment on CAMEL-1461 at 3/26/09 6:42 AM:
-------------------------------------------------------------
Fixed now. The disableReplyTo is now not needed.
trunk: r757693, 757730, 758617
1.x: 757728, 758638
was (Author: davsclaus):
Fixed now. The disableReplyTo is now not needed.
trunk: r757693, 757730, 758617
1.x: 757728
> 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.
[jira] Issue Comment Edited: (CAMEL-1461) A request route with a
topic node incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ 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:42 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 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.
> 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 life 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: 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51029#action_51029 ]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
> So I think we can address both of the use cases if we were to still propagate replyTo and correlationID but honor the inOnly pattern of the to() endpoints even
> if the endpoint prior to it in the chain was an in-out
Yeah, that should be our goal. We agree here.
That should already be possible if you set the *preserveMessageQos=true* option in the *to*. That instructs Camel JMSProducer to _not_ drop the JMSReplyTo/JMSCorrelationID. See JMSProducer.java around codeline 275.
Eg we kinda have reverse the problem between your bridge and Michaels use-case, for which must configure the JMS endpoints with special options.
Before Michael had to se the disableReplyTo=true on his from route. This was in fact quite wrong as the consumer could have been a non Camel one.
Well never the less its fixed now.
Now its your situation that has to set the special *preserveMessageQos=true* on the to endpoint, eg when sending.
So dont we have the solution now?
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51031#action_51031 ]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
Marat,
> 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.
Did you try the option I suggested?
> Please take a look at the patch attached. I think this will keep all happy.
Thanks a lot for the patch and that you kept pushing your views. And not the least had the patience to explain it in details so I could understand it :)
I have applied the patch:
trunk: 762047
1.x: 762050
> 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.
Agree
> 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.
Agree if you by decoupled mean the original request/reply pattern - eg the original caller JMSReplyTo should be decoupled from the JMSReplyTo that came over the topic.
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (CAMEL-1461) A request route with a
topic node incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ 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:40 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 life 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.
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50758#action_50758 ]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
Have you tried the inOnly() DSL
{code}
from
to
inOnly("activemq:topic:news")
to
{code}
> 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
>
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50769#action_50769 ]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
Okay I got this boiled down to
- when you sent an inOnly to the jms topic the JMSReplyTo is still there from the original JMS Message. This one needs to be cleared so Camel wont try to send a reply from the topic.
This can however be disabled on the endpoint with {{"activemq:topic:news?disableReplyTo=true"}}.
> 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
>
> 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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51027#action_51027 ]
Marat Bedretdinov commented on CAMEL-1461:
------------------------------------------
Claus,
Ok I think there are a couple of things going on. My tests are failing not due to replyTo being set to null but rather correlationID set to null. I'll explain bellow.
So let's take a look at the original requirement again.
> 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.
So shouldn't his route look like this?
/* 1 */ from("activemq:queue:inbox")
/* 2 */ .inOnly("mock:inbox")
/* 3 */ .inOnly("activemq:topic:order")
/* 4 */ .beanRef("orderService", "handleOrder");
So the steps are
- Either a native JMS client or CamelTemplate send a message with replyTo != null to (1)
- (1) would propagate the replyTo and correlationID and will expect a reply for up to timeout
- (2) and (3) and (4) should send the messages along without expecting the reply, *but still propagating replyTo and correlationID*
Now whatever endpoint (2, 3, 4) or some external consumer off (3) would take that replyTo and correlationID values and will send the reply back to (1) completing the flow
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
Now the reason my tests are all going busts is because of the following:
I have a bridge scenario between two independent JMS brokers say AMQ and WMQ with XA in between. I need to use two one way routes in order to accommodate that due to transactional semantics.
/*1 */ from("amq:queue:request").to("mq:queue:request");
/*2 */ from("mq:queue:reply").to("amq:queue:reply");
So in order to be able to correlate a request message (1) I load a correlationID, but since that change the correlationID is dropped and when (2) writes a reply message I miss them since their correlationID is null now.
So I think we can address both of the use cases if we were to still propagate replyTo and correlationID but honor the inOnly pattern of the to() endpoints even if the endpoint prior to it in the chain was an in-out
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.
[jira] Commented: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51020#action_51020 ]
Claus Ibsen commented on CAMEL-1461:
------------------------------------
Oh and not to forget. 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.
What if the topic was a WebSphereMQ destination?
> 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.
[jira] Issue Comment Edited: (CAMEL-1461) A request route with a
topic node incurs a 20 second wait and refers to the wrong MEP.
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CAMEL-1461) A request route with a topic node
incurs a 20 second wait and refers to the wrong MEP.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-1461:
-------------------------------
Fix Version/s: 1.6.1
2.0.0
> 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.