scheduling questions

I want to integrate a batch console management that lists all available jobs and offers links to start/stop/schedule jobs. Regarding this, I have many questions (please correct me if any assumption is wrong) :

1. What is the typical (recommended use) for the batch environment? One environment per batch (a job launcher, facade, etc with a configured jobConfigurationName and autostart=true) or a generic environement without configured jobName and invoked solely using the run(String name) or run(JobIdentifier id) (this second option will certainely require TaskExecutorJobLauncher, otherwise jobs can only be invoked serially).
2. As I understand, the JobLauncher is the primary class for my purpose. Is there a single instance of this class or is there one instance per job execution ? i.e. is the job launcher a singleton or a protoype?
3. In order to schedule jobs, shall I use the TaskExecutorJobLauncher and provide a TaskExecutor with scheduling capabilities, or shall I encapsulate the JobLauncher in a scheduler?

Maybe all above options are possible, but which one is recommended or, better stated, which one represents best your idea when you designed the framework?

In point 3 from above, if I use the TaskExecutor inside the JobLauncher, I might encounter problems when I schedule a job for a delayed execution, then invoke stop() : NoSuchJobConfigurationException because the job is not registered yet. Is this the way it should be, i.e. invoking start() does not ensure that I can invoke stop() right after ? In this case, I will certainely need to extend the JobLauncher for special delayed execution, by registering Futures in a map and cancelling one of them on stop() invocation, instead of directly stopping the container.

Thanks in advance for your responses.

Good questions, and nice analysis. Thanks.

I think the answer depends on what you need to achieve, though. If you want all your jobs in a single VM, then I would go with a single execution environment, and a TaskExecutorJobLauncher. There is a really basic demo of this in the samples (if you download the source code there is even an Eclipse launcher for it) that lets you control jobs through Jconsole (JMX).

If you needed heavy processing or a large number of jobs, and a single VM was not going to cut it, then I would say you would need to wrap the JobLauncher in s remote call of some sort (e.g. a web service). We do not provide that out of the box.

The question about scheduling is quite interesting. I hadn't thought of doing it via the TaskExecutor itself - the scheduling capabilities there are a bit limited (better suited to delayed execution than a robust traceable schedule). So most people do it the other way round - use a scheduler to start the jobLauncher.

Having said that, I would like to support calling stop() on a job that hasn't started yet. Can you raise an issue in JIRA for us to track that feature?

Thanks for the reply,

I have created a JIRA issue for the JobLauncher support of stop() and delayed jobs (BATCH-241).

I cannot find the Eclipse launcher in the source download : download is only (as far as I can see from your website) available as maven dependencies, not as a complete eclipse project. Maybe can your just name the xml job config(s) that is(are) used for this, as well as other options/classes. I'm quite interested in the JMX option, as this was for me a natural (and easy) solution, or could at least serve as a prototype.

Another natural option for scheduling capabilities is to use an external scheduler (we should have access to some sort of it). In this case, the scheduler invokes shell commands; using separate shell processes has pros and cons :

• + there is no need to integrate to any app server or other such "heavy" environement to run a job : a single java command is OK (but this can prove to be negative if I need enterprise capabilities out of the box, such as JTA, JMS)
• + I'm not facing any concurrency issue if I run multiple jobs in parallel
• - I miss the capability to cleanly interrupt a job or listen to events or such capabilities from outside (but this can be reduced with the use of JMX).

Is this a common situation, or the situation you talked about when you mentioned the use of a scheduler to start the jobLauncher?