camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Fornoville <tom.fornovi...@roots.be>
Subject Re: Quartz in cluster
Date Mon, 03 Feb 2014 14:52:12 GMT
Thanks Claus & Ronny!

Since we're using JBoss Fuse 6.0 we cannot use camel 2.12 features yet
(waiting on the 6.1 release).

If I understand correctly once we upgrade we can specify  our route like
this (provided that the quartz scheduler was configured to use a
jbdc-jobstore):
  <from uri"sftp://{{user}}@{{server}}?password={{password}}&amp;scheduler=quartz2&scheduler.cron=..."
/>

The <pollEnrich> seems to be a solution also but since we're expecting Fuse
6. any day now I'd like to give that a try first.
I'll let you know how it goes.

Kind regards,
Tom

Tom Fornoville
Senior Developer
m: +32 478 65 86 51
www.roots.be


On Mon, Feb 3, 2014 at 3:31 PM, Ronny Aerts <ronny.aerts@intris.be> wrote:

> Hello Tom,
>
> Could the pollEnrich help you?
>
> <from uri="quartz:..." />
> <pollEnrich uri="sftp://{{user}}@{{server}}?password={{password}}"/>
>
> --
> Kind regards,
> Ronny Aerts - Intris nv - Wapenstilstandlaan 47, 2600 Berchem, Belgium
> R&D Integration Architect
> Prince II certified
> Tel: +32-3-326.50.75
> -----Original Message-----
> From: Tom Fornoville [mailto:tom.fornoville@roots.be]
> Sent: maandag 3 februari 2014 15:07
> To: users@camel.apache.org
> Subject: Re: Quartz in cluster
>
> Hi Claus,
>
> Thanks for your answer.
> I read that topic earlier but it's not the configuration of Quartz I'm
> having problems with.
>
> What I would like to know is how I can use a quartz endpoint to trigger
> file pickup.
>
> Right now we have something like:
>   <route>
>       <from uri="sftp://{{user}}@
> {{server}}?password={{password}}&amp;delay={{delay}}"/>
>       ...
>   </route>
>
> And we want to replace the delay with a Quartz scheduler so it should be
> something like:
>   <route>
>       <from uri="quartz:..." />
>       <from uri="sftp://{{user}}@{{server}}?password={{password}}"/>
>       ...
>   </route>
>
> The second <from> doesn't make sense but I don't know how to describe what
> I want this route to do.
>
> Tom Fornoville
> Senior Developer
> m: +32 478 65 86 51
> www.roots.be
>
>
> On Mon, Feb 3, 2014 at 2:52 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>
> > Hi
> >
> > A similar topic was recently debated
> >
> > http://camel.465427.n5.nabble.com/Master-Slave-failover-using-database
> > -lock-tp5746646.html
> >
> > On Mon, Feb 3, 2014 at 2:46 PM, Tom Fornoville
> > <tom.fornoville@roots.be>
> > wrote:
> > > Hello Camel users,
> > >
> > > In our project we have several routes that start from a file (local
> > > filesystem or FTP) and when we're clustering this via Fuse Fabric we
> > > want to ensure that only one instance of the route picks up files.
> > >
> > > Our first thought was to use the Quartz scheduler with a
> > > JDBC-JobStore as described here:
> > >
> > http://quartz-scheduler.org/documentation/quartz-2.x/configuration/Con
> > figJDBCJobStoreClustering
> > >
> > > Is there an example of a working JDBC-JobStore from within Camel?
> > >
> > > Are there other (simpler) solutions to make sure that multiple
> > > routes
> > don't
> > > interfere?
> > >
> > > Best regards,
> > > Tom
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > Red Hat, Inc.
> > Email: cibsen@redhat.com
> > Twitter: davsclaus
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen Make your
> > Camel applications look hawt, try: http://hawt.io
> >
> Intris nv
> Wapenstilstandlaan 47
> B-2600 Berchem
>         Tel.  +32 3 326 50 75
> Fax  +32 3 326 42 23
> www.intris.be<http://www.intris.be/>
>
> DISCLAIMER
> This is an e-mail from Intris. The information contained in this
> communication is intended solely for use by the individual or entity to
> whom it is addressed.
> Use of this communication by others is prohibited. If the e-mail message
> was sent to you by mistake, please notify support@intris.be<mailto:
> support@intris.be>, destroy it without reading, using, copying or
> disclosing its contents to any other person.
> We accept no liability for damage related to data and/or documents which
> are communicated by electronic mail.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message