Fine, I currently work on the 2.3.0 version of /tags. Because I have some trouble to build the trunk.
Ingo > On Tue, Jun 22, 2010 at 4:13 PM, Ingo Düppe <mailing-li...@dueppe.com> wrote: > >> Hi, >> >> does any reason exists for not upgrading camel-quartz to use the current >> quartz version 1.8.1? >> >> > Its been upgraded to 1.8.2 on trunk. > > > >> Regrads >> >> Ingo >> >> Am 04.06.10 14:36, schrieb Ingo Düppe: >> >>> Hi Claus, >>> >>> fine, I might possibly have some time on next monday to create a patch >>> for it. >>> If not then in two weeks after my vacation I will create a patch for it. >>> >>> Regards >>> >>> Ingo >>> >>> Am 04.06.10 06:55, schrieb Claus Ibsen: >>> >>> >>>> Hi Ingo >>>> >>>> On Thu, Jun 3, 2010 at 10:30 PM, Ingo Düppe <mailing-li...@dueppe.com> >>>> wrote: >>>> >>>> >>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>> Ah thanks for point this out. I have created a ticket >>>> https://issues.apache.org/activemq/browse/CAMEL-2788 >>>> >>>> To improve camel-quartz so you can set that volatile option and also >>>> see what we can about the quartz.properties etc. >>>> And to see how we can serialize CamelJob >>>> >>>> >>>> >>>> >>>>> 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"); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > >
