HI Ashwin,
I will try using replyTo. I will say, though, I have successfully
used JMS routes in the past that look like what I had there (with no
replyTo), and the response of the consuming end would be routed back
as a response. But it was synchronous (I was using direct: for the
initial producer, and used ProducerTemplate.asyncCallbackRequestBody
with a Synchronization to get the callback).
I'm just making a guess, maybe you can confirm: are you implying that
using one queue is naturally synchronous, and I need to set up two
queues to be fully asynchronous with JMS? (and therefore use replyTo
and the other queue name to set up two one-way queues?)
And yes, I am trying to acheive what you outline in #3. I do have
long-duration request/replies.
Thanks!
Seth
On Fri, Oct 1, 2010 at 7:08 PM, Ashwin Karpe <aka...@fusesource.com> wrote:
>
> Hi,
>
> There are several issues in your route definition & usage.
>
> 1> I am not sure what the first route
> from("seda:test").to("jms:queue:a.test");
> is doing for you.
>
> 2>Looking at your 2nd route segment, you are sending a request to a JMS
> consumer (jms:queue:a.test).
> The problem is that the JMS Consumer is taking the request as InOnly since a
> "replyTo" parameter has not been set on the Consumer. Any response that this
> Consumer needs to send back has to have a reply destination to send the
> response back.
>
> 3> Not sure what you are attempting with an Async Processor. An Async
> Processor is meant primarily to behave like a producer that sends an
> exchange with a callback along the route. Since a callback has been
> associated with the exchange and set to the next route element, the Async
> Processor thread can effectively go away. When the next route element
> receives the exchange or message and does its job (maybe calls other
> processors synchronously) it expects to receive an modified exchange with a
> done status back. When it does, it invokes the callback provided by the
> AsyncProcessor, at which point, a new AsyncProcessor thread is created and
> the message then can be handled and sent back. Is it were a synchronous
> request, the AsyncProcessor thread would have to be in Thread_WAIT.
> Hence it is more efficient thread-wise in situations where responses may
> arrive after a long duration.
>
> Check out the following links for code samples how to do this and how things
> work
> https://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/async/AsyncEndpointTest.java?view=markup
> AsyncEndpointTest
>
> https://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/async/MyAsyncComponent.java?view=markup
> MyAsyncComponent
>
> Hope this clarifies things.
>
> Cheers,
>
> Ashwin...
>
> -----
> ---------------------------------------------------------
> Ashwin Karpe
> Apache Camel Committer & Sr Principal Consultant
> FUSESource (a Progress Software Corporation subsidiary)
> http://fusesource.com http://fusesource.com
>
> Blog: http://opensourceknowledge.blogspot.com
> http://opensourceknowledge.blogspot.com
> ---------------------------------------------------------
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Using-Asynchronous-Processors-a-little-help-tp3073267p3073501.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
