[jira] Commented: (CAMEL-1954) Proposition - add job scheduling feature to Camel

["Jim Talbut (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58370#action_58370 ] 

Jim Talbut commented on CAMEL-1954:
-----------------------------------

I have a need of something similar to this, though I was thinking of implementing it outside of camel and then have it call camel routes as necessary.
My requirements are for:
* A clustered quartz implementation.
* Jobs configured entirely from code (jobs will be added and removed at runtime, so spring and other configuration files are of limited use for me).

> Proposition - add job scheduling feature to Camel
> -------------------------------------------------
>
>                 Key: CAMEL-1954
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1954
>             Project: Apache Camel
>          Issue Type: New Feature
>            Reporter: Charles Moulliard
>             Fix For: Future
>
>
> Since a couple of days I try to find an easy way to handle "jobs" in Apache Felix Karaf and Camel. In standard, Camel proposes a camel-timer and camel-quartz components but they can only be used inside a camel route. By the way, camel context or camel routes are not "schedulable" like it is possible with Spring batch. So it is not possible to start a route at 9:00 and stop it at 11:00 and to check if the route succeed or fails inside a OSGI server. Of course, if camel is packaged in java standalone application or j2EE server, alternative exist.
> This is why I come with the following idea who could be very interesting for Apache Felix Karaf / Camel in term of enterprise added value.
> Job Scheduler for starting and stopping bundles
> With the help of a quartz configuration file, the kernel of Apache Felix Karaf can check which bundles have to be scheduled (like jobs) and started/stopped. The bundle to be started could be a camel route, .... When the bundle stops or if the thread is still running at the end of the job, this information must be returned to the job scheduler in order to decide what to do (wait and send an alert to administrator to decide what to do). Another interesting feature could be to return fail / succeed to the job scheduler to keep trace of what happen during job execution. This information could be also used to link jobs / bundles together as this is a feature that you have with tool like IBM Tivoli Manager where you can chain jobs.
> Idea about implementation
> Definition of the "scheduler service"  :
> <job id="A" scheduler="ref to quartz cron definition" errorHandlerRef="reference to the error handler who will handle the exception">
> <start ref="routeA"> // bean refering to a camel toute
> <transacted> // can be used when we have transacted job (= routes)
> <choose>
>    <when>
>      <simple>job succeed</simple>
>      <stop ref="routeA"/>
>      <to queue:job:succeed> // can be a queue component where job report information will be send 
>      <start ref=routeB/> // new job (= route to start)
>   </when>
>   <when>
>      <simple>job fails</simple>
>      <to queue:job:fail>
>   </when>
>   ...
> </job>
> Remarks :
> My proposition depends on the following assertions :
> - CamelContexts must be exported/exposed as a blueprint/spring DM/... services,
> - Routes defines in camel context are visible,
> - When the job is started, it will wait to receive from camel route a return parameter : fail or succeed. Maybe this return parameter could be placed as a message in the  scheduler queue that the job context is listening !!
> - If the job does not receive fail or succeed, then it should be possible to stop it though console, mbeans, ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.