On Tue, Jul 14, 2015 at 2:41 PM, jnupponen <[email protected]> wrote: > Hi! > > Thanks for the information, I'll take another approach to the long > redelivery times then. Can you say some number that would still be > acceptable waiting time in redeliveries? > > I don't actually call getContext.stop() in my code but it was in the example > to demonstrate the same effect that typing bundle:stop in Karaf will have. > After that camel-quartz2 bundle needs to be restarted since the > DefaultQuartzScheduler is unable to shutdown. >
Ah yeah sure that triggers the shutdown from an independent thread. So there is a little bug in camel-quartz2. You are welcome to log a JIRA ticket. > Thanks! > -Jussi > > > > Claus Ibsen-2 wrote >> Hi >> >> Its bad practice to have so long redelvery intervals. Its is intended for >> short time processing. If you want so long then off load the messages to >> some persistent store and process from there. >> >> Though we have a ticket in JIRA to allow Camel's error handler to discard >> those pending redeliveries in can of shutdown etc. But its not implemented >> yet. > > > Claus Ibsen-2 wrote >> Hi >> >> Also dont stop Camel from the same thread you process a message. You >> should spin that off to a separate thread, or use controlbus in async mode >> etc. > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Quartz2-problem-with-AsyncDelayedDelivery-tp5769210p5769288.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
