Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com
 designates 74.125.46.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=Z3cejznc837f+wDvWJcwECN5PheY/oep/xtwgcNlNDKv/K5hljy7EVLeoju118o1I8
         ms8NZu4LOOVKydZrSHmvX4PPiRhyT86pzYri8sebstwNhW6ezce2Vknzok/t7BXE37En
         oN5hKLFdfLyMH82GaNPk1nH/ZDR4+qYCQVW5w=
Message-ID: <ec6e67fd0809290743g38bc9f4x5a99945a3d8e3b23@mail.gmail.com>
Date: Mon, 29 Sep 2008 15:43:09 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: Using ExchangePattern.InOut blocks request queue
In-Reply-To: <ec6e67fd0809290734t712cbdd4uc90cc493b700df79@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <19701558.post@talk.nabble.com> <48DED6AA.4020803@gmail.com>
	 <19724861.post@talk.nabble.com>
	 <ec6e67fd0809290734t712cbdd4uc90cc493b700df79@mail.gmail.com>

2008/9/29 James Strachan <james.strachan@gmail.com>:
> 2008/9/29 ee7arh <andrew.hurst@2e-systems.com>:
>>
>> 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:
>>
>> from("jms:queue:myqueue").to("bean:requestProcessor?methodName=processRequest");
>>
>> 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.
>
> Yeah - you can enable more concurrent processing of the requests by
> configuring your JMS component - or via the URI
>
> See
>
> http://activemq.apache.org/camel/jms.html
>
> e.g.
>
> from("jms:queue:myqueue?concurrentConsumers=50").to("bean:requestProcessor?methodName=processRequest");

I've added this to the FAQ
http://cwiki.apache.org/CAMEL/why-does-my-jms-route-only-consume-one-message-at-once.html

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

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