On 31/03/2008, Martin Gilday <[EMAIL PROTECTED]> 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
