2009/3/25 Claus Ibsen <claus.ib...@gmail.com>: > On Wed, Mar 25, 2009 at 10:02 AM, James Strachan > <james.strac...@gmail.com> wrote: >> We maybe need to introduce some clean shutdown mechanism into >> consumers; so we can tell all the consumers we're about to shutdown; >> then they can gracefully stop processing the current route's message - >> then we actually stop the consumers (then the endpoints & components >> etc). Stopping routes midway through (eg cancelling timers) could lead >> to other kinds of warning messages. I guess the downside of this could >> make shutdown take a while to complete - also if routes invoke other >> routes you still could have issues where one route wants to send to >> another route which is now closed. >> >> So its always gonna be pretty hard to shut down Camel cleanly without >> any error messages at all. Maybe we just hide error messages once >> shutdown starts? :) >> >> >> On 25/03/2009, Claus Ibsen <claus.ib...@gmail.com> wrote: >>> On Tue, Mar 24, 2009 at 3:42 PM, Markus Reil <gistenju...@gmx.de> wrote: >>>> >>>> Hi, >>>> >>>> thanks for your help. >>>> But I am still experiencing the same problem. The sleep does not get >>>> interrupted (2.0-M1). >>>> Do you have any idea why this happens? Let me know if you need more >>>> information. >>> Can you show the complete route? And point out where the message is >>> when you shutdown. > Yeah I have given that some thoughts as well. > > I have wondered if we should support several shutdown strategies > - shutdown now > - shutdown > - shutdown graceful > > Shutdown now, is a kinda abrubt shutdown. > > Shutdown is a kinda default shutdown as we do now > > And graceful: > - Should deny any new incoming messages. > - Schedulers should stop triggering > - Exchanges in transit should allow to complete > - And if Camel had a kinda of global state that could monitor if there > were any ongoing exchanges. And thus wait until they completes before > stopping all the routes. > > This global state monitor could however be a hot spot for really high > performance. But I guess smart people have figured out great > solutions. > > And this global monitor can be used in web console to see which in > transit exchanges current exists.
Agreed. Right now DefaultCamelContext has isStopped() and isStopping() methods which consumers could look for; maybe we need to expose some public method which returns true if a consumer should continue processing (and if it returns false then they should gracefully shut down). e.g. we add some method like this to CamelContext API /** Returns true if a consumer can continue processing or false if it should gracefully stop */ boolean isConsumeAllowed(); Things like Guice/Spring have lifecycle support so will shut down the CamelContext and any related services; so maybe we just need some gracefulShutdown flag we can enable - which causes the doStop() in DefaultCamelContext to wait for all the consumers to be stopped before closing any endpoints/producers/services? To implement this we might need to register all consumers in the CamelContext until they are stopped maybe... -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
