camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ingo Düppe <mailing-li...@dueppe.com>
Subject Re: Clustering with camel-quartz
Date Thu, 03 Jun 2010 20:30:56 GMT
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-lists@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-lists@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");
>>        }
>>    }
>> }
>>
>>
>>
>>
>>
>>     
>
>
>   


Mime
View raw message