camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ee7arh <>
Subject Re: Using ExchangePattern.InOut blocks request queue
Date Mon, 29 Sep 2008 14:21:54 GMT

Hi Willem,

Thanks for your answer.

I've actually solved the issue now using Spring Remoting but will explain in
more detail my original dilema since it took us a lot of hardwork and
searching to "stumble upon" the solution ;)

Perhaps I should first clarify that what I was trying to achieve was to
replace RMI with Camel [using JMS underneath] within my application. I had a
multi threaded client application one 1 side which sent requests to an RMI
server application on the other side. Standard client/server stuff, sort of
like a WebServer where requests are in effect able to be processed by the
server in parallel (although each request is atomic).

So instead of starting up an RMI server, I replaced this with Camel. My
routes were configured something like this:


In my former RMI "Impl" class which actually did the service processing on
the server side, instead of extending UnicastRemoteObject, I now just added
the following annotation at the top of the class:

@Service(value = "requestProcessor")

And within that class I had a method called "processRequest()".

The behaviour I wanted was that whenever a client thread wanted the server
to process a service request, it would use the ExchangePattern.InOut when
calling sendBody() like so:

myResponseObject = (MyResponse)camelTemplate.sendBody("jms:queue:myqueue",
ExchangePattern.InOut, myReqObject);

This seemed to work fine but I noticed that the server would process only 1
client request at a time. I guess this is because there is actually only a
single consumer on the server side reading off the underlying JMS queue.

To acheive true Request/Response, I have turned to "Spring Remoting" to get
this working (which it now does having followed the examples provided - link
below [2] ). 

Do you think this is the right strategy in the end or was there something I
missed along the way which would I mean I can use pure Camel?



willem.jiang wrote:
> Hi
> Can you show me you route configure file and your client request sending 
> code ?
> I checked the ProducerTemplate code , there is no any synchronized token.
> According the wiki page[1], the JMS component should support the 
> parallel processing.
> [1]
> Willem
> ee7arh wrote:
>> Hi,
>> I wonder if anyone can point out where I'm going wrong, maybe I'm missing
>> something conceptually.
>> I have a multi-threaded client application which wants to do
>> request/response with a camel server application and I am trying to use
>> the
>> ExchangePattern.InOut when calling the sendBody() on the Producer.
>> The behaviour I am observing is that if say 3 client threads try to call
>> the
>> sendBody() method at the same time (i.e. try to send a request to the
>> server
>> and wait for a response), only 1 client thread at a time will be able to
>> do
>> some processing and the others effectively block until the processing of
>> the
>> one in front finishes. So rather than processing taking place in
>> parallel,
>> it takes place sequentially one after the other.
>> I know that sendBody() with the ExchangePattern.InOut pattern is a
>> synchronous call, that's fine and how I want it. But I am surprised that
>> the
>> queue blocks when attempting multi threading because the JMS
>> request/response pattern described in ActiveMQ makes use of temporary
>> destinations to send responses back matching back using correlationIds.
>> Could anybody confirm if my assumptions are correct and if so, what could
>> be
>> the problem?

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message