Hi Claus, well I'm not sure if it is right. But I guess if the trigger is marked as volatile it will be automatically removed within in the database. Normally volatile jobs won't be stored in a db but in a cluster environment they will be.
The problem with camel is, that I cannot define an volatile trigger like "quartz://trigger?job.volatility=true&cron..." and also define a cluster environment within the quartz.properties. This is because CamelJob isn't serializable. As I mentioned I haven't dig into it very deep. I just wanted to be sure, that I didn't miss something obviously before I invest time into it. Regards Ingo Am 03.06.10 15:08, schrieb Claus Ibsen: > Hi > > If you have the app crash using kill -3 / -9 and then start it again > and expect quartz to recover and it does not. > Then I think you should ask at the Quartz user forum about this. > > And maybe you can create a plain example with pure Quartz to not > pollute the example with Camel as the Quartz guys would just say its a > Camel problem. > Just as I say its most likely a Quartz problem :) > > And if there is something that must be configured / tweaked in Quartz > to have this working then let us know. Maybe there is something we can > do easier in camel-quartz for that. > > > > On Thu, Jun 3, 2010 at 12:08 PM, Ingo Düppe <mailing-li...@dueppe.com> wrote: > >> Am 01.06.10 08:37, schrieb Claus Ibsen: >> >>> On Mon, May 31, 2010 at 6:48 PM, Ingo Düppe <mailing-li...@dueppe.com> >>> wrote: >>> >>> >>>> I forgot to mention that I currently use version 2.2.0. >>>> >>>> >>>> >>> Can you create a small sample application that demonstrates this? Then >>> its much easier to look into it to see what / if we can do in Camel. >>> >>> >>>> - Ingo >>>> >>>> >>>> >>>> >> Sure, i created a small example that you can find at >> http://dl.dropbox.com/u/4043036/quartz-cluster.tar.gz. >> >> It contains just a small JUnit Test Case (see below). The test runs fine >> as long you execute the whole test. As I find out yesterday, quartz >> deletes some information within the database on a clean shutdown. >> So the next test run will also run fine. >> But if you kill the running test - to simulate a server crash - the next >> test run will end up with an exception. >> >> So how do I handle such inconsist data on startup of camel? >> >> Regards >> Ingo >> >> @RunWith(SpringJUnit4ClassRunner.class) >> @ContextConfiguration( >> locations = { >> "classpath*:context-test.xml" >> } >> ) >> public class QuartzClusterTest extends TestCase { >> >> @Autowired >> private CamelContext camelContext; >> >> @EndpointInject(uri = "mock:result") >> protected MockEndpoint resultEndpoint; >> >> @Test >> @DirtiesContext >> @Repeat(value=2) >> public void testTriggering() throws Exception { >> camelContext.addRoutes(new QuartzRouteBuilder()); >> resultEndpoint.setMinimumExpectedMessageCount(5); >> resultEndpoint.setResultWaitTime(5000L); >> resultEndpoint.assertIsSatisfied(); >> } >> >> public static class QuartzRouteBuilder extends RouteBuilder { >> >> @Override >> public void configure() throws Exception { >> >> from("quartz://trigger?stateful=true&cron=0/1+*+*+*+*+?").to("mock:result"); >> } >> } >> } >> >> >> >> >> >> > > >
