camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Chen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-1366) EndpointMessageListener should respect ExchangePattern
Date Thu, 26 Feb 2009 17:12:00 GMT

    [ https://issues.apache.org/activemq/browse/CAMEL-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50050#action_50050
] 

Michael Chen commented on CAMEL-1366:
-------------------------------------

Actually, the logic in EndpointMessageListener.createExchange() made it impossible. If disableReplyTo
is set to true, the "org.apache.camel.jms.replyDestination" will not be set.  Downstream processor
will have no way to know how to reply.

Since we have talked about it, I want to *reinstate* the original change suggestion *plus*
the following. In the createExchange() method, these lines:
{code}//
        if (replyDestination != null && !disableReplyTo) {
            exchange.setProperty("org.apache.camel.jms.replyDestination", replyDestination);
            exchange.setPattern(ExchangePattern.InOut);
        }
{code}
should be changed to:
{code}//
        if (replyDestination != null && !disableReplyTo) {
            exchange.setProperty("org.apache.camel.jms.replyDestination", replyDestination);
            if (!exchange.getPattern().isOutCapable())
                exchange.setPattern(ExchangePattern.InOut);
        }
{code}
This change will account for ExchangePattern.InOptionalOut. However, it will also require
the fix for bug CAMEL-1384 I submitted yesterday for everything to work.  In summary, a route
could be defined as:
{code}
from("activemq:my_queue?exchangePattern=InOptionalOut").to("predict_weather://?reply_later=true");
{code}
Then if and only if the last processor does NOT set a out message, camel.jms will not sent
a reply.  It is the downstream processors' responsibility to use property "org.apache.camel.jms.replyDestination"
to construct and sent the JMS reply message.

The two changes in this bug and CAMEL-1384 are 100% backward compatible, since InOptionalOut
has not been considered for camel.jms before.


> 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.


Mime
View raw message