Regarding the thread pool comment... what is the impact of a
long-running request on thread consumption? If I understand correctly:
- one of the consumer threads will be occupied; so if I configure
"concurrentConsumers=50", then it would consume one of those 50 threads.
- the thread performing the request on the producer side will block
waiting for the response.
Is this correct?
Thanks,
Jim
On 12/20/2010 9:24 PM, Willem Jiang wrote:
Hi
I don't think set the time out to be hours is go choice, if you have
lots of this kind of long running request, they will eat up your
thread pool, and the camel route will not take any message any more.
The other choice you be leverage the JMS async nature and link the
request and response with correlation ID. Maybe you need to improve
your remote interface to provides an async call back API to make sure
there is no blocking thread to wait for the response.
Willem
On 12/21/10 7: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
