Hi, does any reason exists for not upgrading camel-quartz to use the current quartz version 1.8.1?
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"); >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > > >
