camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Request Reponse with Camel
Date Mon, 31 Mar 2008 18:19:36 GMT
On 31/03/2008, Martin Gilday <> wrote:
> > So the missing bit of functionality is to be able to mark operations
>  > on your bean as being asynchronous; so that the client side doesn't
>  > block waiting for the results.
> No I'm not sure that's what I mean.  I want the route to place onto the
>  2nd (or nth) JMS queue after a bean invocation, but not have the route
>  wait for the consumer of that JMS queue to return.

So the bean invocation is async (it doesn't wait to consume the
response). Though rather than using a temporary queue, you wanna
specify the reply-to destination right?

i.e. its an async invocation; but the JMSReplyTo destination is specified.

> So the placing on
>  the "to" is async not the consuming, or is this the same thing? Does
>  that seem like a reasonable thing to be trying to do?
>  So it would be something like:
>  from("test-jms:queue:test.queue")
> .beanRef("tradingService", "trade")
>  .choice().when(header("distribute").isEqualTo(true)).to("test-jms:queue:data.distribution.queue",
>  ExchangePattern.InOnly)  //PATTERN SPECIFIED HERE
>  .end();
>  from("test-jms:queue:data.distribution.queue")
>  .beanRef("distributionService", "distribute");

Oh hang on a minute - I think we were just talking at cross purposes :)

I was talking about the Spring Remoting - the client side invoking a
bean causing JMS operations to occur. I was talking about the client
invoking the bean blocking waiting to consume the JMS message
containing the response.

The route you've described is the server side; consuming a message,
invoking a bean and sending the response to whatever queue you want.
If so thats fine.

If an inbound JMS message has a JMSReplyTo header specified, then
it'll automatically forward to whereever the caller requested.

i.e. if someone sends a message with a JMSReplyTo header specified to
the 2nd queue, it'll just do the right thing if you do

from("jms:someQueue").bean("someBean", "method");

If you want to override/customize the JMSReplyTo header you could
explicitly specify the header in a transform before invoking the bean.
 Or you could disable the header and then just have an explicit to()
after the bean invocation. You're call really.

>  As this hasn't already been required by Camel developers I'm thinking
>  that maybe I am going about this the wrong way?  I think what I am after
>  is just a routing slip,

BTW we've a Routing Slip now...

> but some parts of the route are just drops onto
>  queues which are processed async without a reply.  My use case is that a
>  queue consumer process trades and gives back a response (a buyer id and
>  price).  Depending on the type of trade there may be a need to trasmit
>  data to an external client.  As this is a long running process it should
>  not block, as the original caller is waiting for the trade result.
>  Ideally "tradingService" should not be aware of the different types of
>  trade outcomes, which is why I am attempting to use a choice based on
>  headers sent in.
>  I have also found that when using InOut and having both bean signatures
>  as 'void' then BOTH the client and server fail with:
>  2008-03-31 16:47:32,421 DEBUG
>  [org.apache.camel.component.jms.JmsProducer] Future timed out
>  I can see both bean consumers for each JMS queue are executing through
>  logging.  The timeout makes sense as there is no Out to be sent back.
>  This seems like expected behavious (altough should this log statement's
>  level be debug?), so it would be nice if Camel could detect that you
>  have specified InOut on a route that cannot return.

Even for a void return, it could return an exception though. i.e. not
returning anything is different to throwing a runtime exception.

>  Thank you for assisting me whilst I learn Camel.

You're most welcome! Sorry this stuff isn't as clear as it should be
from the docs


Open Source Integration

View raw message