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"); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
