It looks like there is problem on that page, because instead of source snippets I see this error message
"Error formatting macro: snippet: java.lang.IndexOutOfBoundsException: Index: 20, Size: 20 " No idea where it is coming from, because in edit/preview mode, the page is rendered fine Bilgin On 6 February 2012 06:07, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > I have updated the FAQ with better examples how to stop a route (or > Camel) from a route > https://cwiki.apache.org/confluence/display/CAMEL/How+can+I+stop+a+route+from+a+route > > The source code for the example will be committed, when ASF SVN again works. > > There was in fact more problems with the old FAQ to stop a route using > the same thread. > Not only the problem identified by Babak, but you also have problem, > that when the route is stopped > it may close resources and whatnot currently in-use, that the current > message was needed to use > when it is done. For example a JMS consumer with TX would need to ack > the message etc. > A mail message need to set a SEEN flag on the mail etc. > > So spinning off a new thread to stop a route is best practice, this is > also how you would normally stop routes, or the application itself. > > On Sun, Feb 5, 2012 at 4:34 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> Hi >> >> No we should not do that. >> >> People should really not stop a route using the same thread that is >> process currently messages from a route. But instead let another >> thread stop the route. >> >> There is no good solution for stopping a route with the same thread in >> mid flight of processing messages on a route. Its like sawing off the >> branch you are sitting on. >> >> I have added a note on the FAQ. >> >> >> >> On Sun, Feb 5, 2012 at 4:28 PM, Babak Vahdat >> <babak.vah...@swissonline.ch> wrote: >>> Hi Claus, >>> >>> with the usage of ScheduledBatchPollingConsumer and it's derivates inside >>> routes there's an issue while doing context.stopRoute("myCoolRoute") as >>> Camel tries to shutdown the route gracefully and as the mentioned class >>> does: >>> >>> if (answer == 0 && isPolling()) { >>> // force at least one pending exchange if we are polling as >>> there is a little gap >>> // in the processBatch method and until an exchange gets >>> enlisted as in-flight >>> // which happens later, so we need to signal back to the >>> shutdown strategy that >>> // there is a pending exchange. When we are no longer polling, >>> then we will return 0 >>> LOG.trace("Currently polling so returning 1 as pending >>> exchanges"); >>> answer = 1; >>> } >>> >>> it waits and waits until the (30 seconds) timeout reaches although no *real* >>> inflight exchanges are available at all! I realized this behavior as I was >>> trying to provide a working example for the user (you see already by this >>> thread). >>> >>> However doing main.stop() (as by the upper example) did *not* behave like >>> this! >>> >>> A possible fix (may be dirty) would be to check that if we already returned >>> X times a hard-coded value of 1 then we should better return 0 instead to >>> signal there's no real inflight exchange available. >>> >>> Babak >>> >>> >>> -- >>> View this message in context: >>> http://camel.465427.n5.nabble.com/File-consumer-waiting-for-it-to-start-tp5455062p5458048.html >>> Sent from the Camel - Users mailing list archive at Nabble.com. >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: cib...@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/
