On Wed, Mar 25, 2009 at 10:49 AM, James Strachan <james.strac...@gmail.com> wrote: > 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(); Well what if a consumer is part of an internal route as well. eg the seda component can be used to bind routes together.
So if we stop the seda consumer and there are some routes active with messages being routed to this consumer? They will fail then. I guess its hard to stop any outside bound consumers/messages coming in. > > > 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/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
