camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marat Bedretdinov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-1461) A request route with a topic node incurs a 20 second wait and refers to the wrong MEP.
Date Sat, 04 Apr 2009 20:31:34 GMT

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


Mime
View raw message