camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Newsham <>
Subject Re: long-running requests over jms
Date Tue, 21 Dec 2010 23:49:39 GMT

Thanks for the responses Claus and Willem.  I couldn't find a JIRA issue 
related to jms exchange store, etc.  I opened a new JIRA issue for 
long-running jms requests:

I'm trying to understand the pluggable store you're referring to.  I 
think what you're saying is that the pluggable store is purely 
consumer-side, where the consumer would notice a long-running request, 
park the exchange in the store, and release the consumer thread, then 
when the result becomes available, it would pick up the exchange again 
and send it on.  Did I understand correctly?  And the purpose would be 
to free the consumer thread?

I can see the potential problem that if a lot of long-running requests 
are made, some thread pool might be exhausted.  For our own purposes, 
I'm not too worried about this problem as the long-running requests will 
be rare and exceptional cases and we have small enough load and can 
afford to configure a large enough thread pool so that it's not an 
issue.  So for us, the primary issue is that there's no way for the 
producer to be aware that the consumer is still processing the request 
(since setting requestTimeout to a large value is not a good idea).


On 12/21/2010 4:43 AM, Claus Ibsen wrote:
> Hi
> We have some thoughts of letting camel-jms support using a pluggable
> store so it can persist the in flight Exchange. And then on the reply
> consumer side, it can peek in the store to find the correlated
> Exchange and load it from the store, and continue routing the
> Exchange.
> Then we can support long use-cases. Also if Camel crashes or you shutdown Camel.
> I think we have created a JIRA ticket for it, I may be mistaken. Fell
> free to see if you can dig out the JIRA.
> If not create a new one and refer to this thread (using nabble etc.)
> On Tue, Dec 21, 2010 at 12:27 AM, Jim Newsham<>  wrote:
>> Hi everyone,
>> We are using Camel + ActiveMQ, with InOut messages and bean() routes, as a
>> form of flexible remoting (remote service invocation).  This has been
>> working out quite well for us so far.  One issue that we've run into is that
>> while most service requests complete very quickly, some particular service
>> requests can take a long time to execute (due to the processing they must
>> perform) -- perhaps many minutes, or in extreme cases possibly an hour or
>> more.  However, if the request exceeds the configured jms "requestTimeout"
>> parameter, then the requester will receive a timeout exception.
>> I feel that the requestTimeout parameter alone is not flexible enough to do
>> what we need.  requestTimeout should be a somewhat small value so that the
>> application is responsive to disconnects (we certainly can't set it to an
>> hour; the 20 sec default seems reasonable).  By contrast, there doesn't seem
>> to be a very well-defined, reasonable upper bound on the long-running
>> requests -- they could take an hour, perhaps more.
>> I feel that what we need to ensure responsiveness while supporting
>> long-running requests is some form of periodic, pending request heartbeat.
>>   Coding this on an ad-hoc basis per request would be tedious and cumbersome.
>>   It would be great if I could set a "requestTimeout" on the producer
>> endpoint (let's say 20s), and configure the consumer endpoint with a
>> heartbeat "requestKeepalive" parameter (let's say 15s), and the consumer
>> would send periodic messages to the producer which would reset its timeout
>> counter, until the consumer finally sends the result.
>> What do you think?  Is such a proposal feasible?  Any alternative ideas?  I
>> took a look at the jms component code, but I'm not quite sure where the
>> producer timeout happens, or where a consumer keepalive processor would go.
>> Thanks,
>> Jim

View raw message