camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Request Reponse with Camel
Date Mon, 31 Mar 2008 18:19:36 GMT
On 31/03/2008, Martin Gilday <martin.lists@imap.cc> 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...
http://activemq.apache.org/camel/routing-slip.html

> 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

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Mime
View raw message