camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Newsham <jnews...@referentia.com>
Subject long-running requests over jms
Date Mon, 20 Dec 2010 23:27:59 GMT

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

Mime
View raw message