[jira] Commented: (CAMEL-1366) EndpointMessageListener should respect ExchangePattern
[
https://issues.apache.org/activemq/browse/CAMEL-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=50068#action_50068
]
Claus Ibsen commented on CAMEL-1366:
trunk: Committed revision 748476.
EndpointMessageListener should respect ExchangePattern
--
Key: CAMEL-1366
URL: https://issues.apache.org/activemq/browse/CAMEL-1366
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
In all current releases,
org.apache.camel.component.jms.EndpointMessageListener.onMessage() has the
following logic (line 90 in 1.6.0 code):
{code}
// send the reply
if (rce == null body != null !disableReplyTo) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This logic should also respect ExchangePattern of the exchange, so I propose
a change to:
{code}
// send the reply
if (rce == null body != null exchange.isOutCapable()) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This change allows a processing pattern where the route may change the
ExchangePattern using methods like RouteBuilder.inOnly() to switch the MEP at
will so that the reply is send at a later time (true asynchronous exchange).
This processing pattern is particularly useful for integrating long running
services. For example,
{code}
// Java DSL
from(activemq:my_queue?exchangePattern=InOnly).to(predict_weather://?reply_later=true);
// or
from(activemq:my_queue2).inOnly().to(predict_weather://?reply_later=true);
{code}
The flaw of the current logic makes it impossible to do true asynchronous
exchange, because 1) it does not respect the ExchangePattern; 2) if property
disableReplyTo is used, the org.apache.camel.jms.replyDestination
property will not be set (see method createExchange in the same file), thus
downstream cannot find the reply destination.
The proposed change can also deprecate the disableReplyTo property and put
the MEP concept into good use.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1366) EndpointMessageListener should respect ExchangePattern
[
https://issues.apache.org/activemq/browse/CAMEL-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=50017#action_50017
]
Claus Ibsen commented on CAMEL-1366:
@Michael
That is actually a good idea. The reply can be done later as you say.
But isnt that supported already with the disableReplyTo option?
{code}
from(activemq:my_queue?disableReplyTo=true).to(predict_weather://?reply_later=true);
{code}
EndpointMessageListener should respect ExchangePattern
--
Key: CAMEL-1366
URL: https://issues.apache.org/activemq/browse/CAMEL-1366
Project: Apache Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 1.6.0
Environment: ActiveMQ/Camel
Reporter: Michael Chen
In all current releases,
org.apache.camel.component.jms.EndpointMessageListener.onMessage() has the
following logic (line 90 in 1.6.0 code):
{code}
// send the reply
if (rce == null body != null !disableReplyTo) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This logic should also respect ExchangePattern of the exchange, so I propose
a change to:
{code}
// send the reply
if (rce == null body != null exchange.isOutCapable()) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This change allows a processing pattern where the route may change the
ExchangePattern using methods like RouteBuilder.inOnly() to switch the MEP at
will so that the reply is send at a later time (true asynchronous exchange).
This processing pattern is particularly useful for integrating long running
services. For example,
{code}
// Java DSL
from(activemq:my_queue?exchangePattern=InOnly).to(predict_weather://?reply_later=true);
// or
from(activemq:my_queue2).inOnly().to(predict_weather://?reply_later=true);
{code}
The flaw of the current logic makes it impossible to do true asynchronous
exchange, because 1) it does not respect the ExchangePattern; 2) if property
disableReplyTo is used, the org.apache.camel.jms.replyDestination
property will not be set (see method createExchange in the same file), thus
downstream cannot find the reply destination.
The proposed change can also deprecate the disableReplyTo property and put
the MEP concept into good use.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1366) EndpointMessageListener should respect ExchangePattern
[
https://issues.apache.org/activemq/browse/CAMEL-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=49993#action_49993
]
Michael Chen commented on CAMEL-1366:
-
exchange.isOutCapable() is always true downstream due to the logic in method
EndpointMessageListener.createExchange(). That method forces the MEP to be
InOut if JMSReplyTo is present in the original request.
If your reason for forcing a reply is to honor the JMS spec, I can't argue
otherwise. Please close this bug.
However, I believe the camel.component.jms implementation should offer the
option of not replying the original request and give that job to other
components or processors downstream. This does not break the JMS spec, but
just a matter of which Camel component is replying.
EndpointMessageListener should respect ExchangePattern
--
Key: CAMEL-1366
URL: https://issues.apache.org/activemq/browse/CAMEL-1366
Project: Apache Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 1.6.0
Environment: ActiveMQ/Camel
Reporter: Michael Chen
In all current releases,
org.apache.camel.component.jms.EndpointMessageListener.onMessage() has the
following logic (line 90 in 1.6.0 code):
{code}
// send the reply
if (rce == null body != null !disableReplyTo) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This logic should also respect ExchangePattern of the exchange, so I propose
a change to:
{code}
// send the reply
if (rce == null body != null exchange.isOutCapable()) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This change allows a processing pattern where the route may change the
ExchangePattern using methods like RouteBuilder.inOnly() to switch the MEP at
will so that the reply is send at a later time (true asynchronous exchange).
This processing pattern is particularly useful for integrating long running
services. For example,
{code}
// Java DSL
from(activemq:my_queue?exchangePattern=InOnly).to(predict_weather://?reply_later=true);
// or
from(activemq:my_queue2).inOnly().to(predict_weather://?reply_later=true);
{code}
The flaw of the current logic makes it impossible to do true asynchronous
exchange, because 1) it does not respect the ExchangePattern; 2) if property
disableReplyTo is used, the org.apache.camel.jms.replyDestination
property will not be set (see method createExchange in the same file), thus
downstream cannot find the reply destination.
The proposed change can also deprecate the disableReplyTo property and put
the MEP concept into good use.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1366) EndpointMessageListener should respect ExchangePattern
[
https://issues.apache.org/activemq/browse/CAMEL-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=49964#action_49964
]
Claus Ibsen commented on CAMEL-1366:
@Michael
The last one is not a bug. inOnly, inOut is used to affect/change the MEP on
route.
What you are asking for is on the consumer side (jms consumer, the from node)
to set it to request only, or request-reply.
However the jms spec has this JMSReplyTo that we should honor. So if someone
sends a JMS message to a queue with a JMSReplyTo header then that caller would
expect a reply on that destination and thus Camel should honor this and return
a reply.
So today you can do what you want:
{code}
from(activemq:my_queue).to(predict_weather://?reply_later=true);
{code}
If the message sent to my_queue does NOT contain a JMSReplyTo then its a
request only.
However what we could consider is to also test for exchange.isOutCapable() and
send a null body if the test fails to signal no/empty reply.
EndpointMessageListener should respect ExchangePattern
--
Key: CAMEL-1366
URL: https://issues.apache.org/activemq/browse/CAMEL-1366
Project: Apache Camel
Issue Type: Bug
Components: camel-jms
Affects Versions: 1.6.0
Environment: ActiveMQ/Camel
Reporter: Michael Chen
In all current releases,
org.apache.camel.component.jms.EndpointMessageListener.onMessage() has the
following logic (line 90 in 1.6.0 code):
{code}
// send the reply
if (rce == null body != null !disableReplyTo) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This logic should also respect ExchangePattern of the exchange, so I propose
a change to:
{code}
// send the reply
if (rce == null body != null exchange.isOutCapable()) {
sendReply(replyDestination, message, exchange, body);
}
{code}
This change allows a processing pattern where the route may change the
ExchangePattern using methods like RouteBuilder.inOnly() to switch the MEP at
will so that the reply is send at a later time (true asynchronous exchange).
This processing pattern is particularly useful for integrating long running
services. For example,
{code}
// Java DSL
from(activemq:my_queue?exchangePattern=InOnly).to(predict_weather://?reply_later=true);
// or
from(activemq:my_queue2).inOnly().to(predict_weather://?reply_later=true);
{code}
The flaw of the current logic makes it impossible to do true asynchronous
exchange, because 1) it does not respect the ExchangePattern; 2) if property
disableReplyTo is used, the org.apache.camel.jms.replyDestination
property will not be set (see method createExchange in the same file), thus
downstream cannot find the reply destination.
The proposed change can also deprecate the disableReplyTo property and put
the MEP concept into good use.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
