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 <jnews...@referentia.com> 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 > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
