camel-users mailing list archives

One of the main reasons we can't use Quartz is because corporate already uses
a scheduler of their choice, and they already have a lot of configuration in
there such as holiday schedules (many many different holiday schedules in
fact). Their scheduler is also already tied into the alerting system so all
that stuff was set up in there too (email server config, email address
lists, etc. etc.).
Since our routes have to obey the same holidays and email config and
whatnot, we didn't see any practical way to do so without using their actual
scheduler.
Ramkumar.Iyer wrote
> I am familiar only with Quartz for scheduling. Why was it not an easy
> solution ? I remember (before getting introduced to CAMEL) storing the
> actual job to be processed as a bean in a trigger(along with a vector of
> future jobs to be processed after this job) and this job would be
> de-serialized from database and executed and a new job may be created in
> place.
>
> The algo basically was
>
> Scheduler wakes up; Fires DB job; Job Unmarshalls; Executes logic; Updates
> execution history; Points to next job
>
> How can this be done for external scheduler ? Will using a database solve
> this problem ? The above logic can be a CAMEL Logic. We used to run the
> above on cluster as most jobs were decoupled among themselves and acted on
> computing values on read only data?
>
> -----Original Message-----
> From: Christian Müller [mailto:
> christian.mueller@
> ]
> Sent: Wednesday, October 31, 2012 4:29 AM
> To:
> users@.apache
> Subject: Re: external scheduler integration
>
> We have similar requirements.
> An external scheduler (Tivoli) is used to trigger some batch processing
> (reading and processing large files). The trigger happens via HTTP and
> provides the file name which should be processed.
> After we finished the processing (multiple routes which are decoupled by
> queues) we have to return the HTTP call with a status code. Like 0 == OK,
> 1
> == Error 1, 2 == Error 2, ... And of course, we have to stop the route...
>
> For this, we have implemented our own solution because this was not
> possible with a route policy (we need something like a "use case policy").
> We use the Camel API to start/stop routes, to track inflight messages and
> whether they failed or not. Not an easy solution at this time...
>
> Best,
> Christian
>
> On Sun, Oct 28, 2012 at 4:48 PM, bung_ho &lt;
> bung_ho@
> &gt; wrote:
>
>> For various reasons it's not practical to use quartz etc to schedule my
>> routes, all the scheduling must be done using the corporate scheduler. I
>> have searched the forums and it seems all scheduler discussion is based
>> on
>> the built-in quartz/cron etc.
>>
>> Anyway my idea to integrate with the external scheduler is simply to use
>> a
>>
> <from uri="file: ..." />
> that looks for a marker file that will be placed
>> by
>> the external scheduler, this will tell the route when to run. I figure
>> also,
>> the route can drop another marker file at the end to report success or
>> failure; the external scheduler can also be made to look for these files
>> to
>> get the job status.
>>
>> Can anyone think of any drawbacks to this approach, or have any better
>> suggestions?
>>
>> Thanks
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/external-scheduler-integration-tp5721668.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> This e-mail and any files transmitted with it are for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information. If you are not the intended recipient(s), please reply to the
> sender and destroy all copies of the original message. Any unauthorized
> review, use, disclosure, dissemination, forwarding, printing or copying of
> this email, and/or any action taken in reliance on the contents of this
> e-mail is strictly prohibited and may be unlawful.
--
View this message in context: http://camel.465427.n5.nabble.com/external-scheduler-integration-tp5721668p5721976.html
Sent from the Camel - Users mailing list archive at Nabble.com.