I recently came across this interesting question on Job Scheduling in Java in the widely popular experts-exchange website. Unfortunately, you require subscription to see “expert” answers, unlike Stack Overflow. Here is my take on this FAQ:

1) Is it possible to use Sun’s own java.util.TimerTask for my complex report scheduling?

Timer facility has limited capabilities when compared to JDK 5 concurrency utilities. This is best explained in Chapter 6 (6.2.5 Delayed and periodic tasks) of Java Concurrency In Practice by Brian Goetz, the best Java concurrency book on the planet. Fortunately, you can access this sample chapter Task Execution.

Here is the gist from the book (for the impatience):

a) A Timer creates only a single thread for executing timer tasks. If a timer task takes too long to run, the timing accuracy of other TimerTasks can suffer.

b) Another problem with Timer is that it behaves poorly if a TimerTask throws an unchecked exception. The Timer thread doesn’t catch the exception, so an unchecked exception thrown from a TimerTask terminates the timer thread. Timer also doesn’t resurrect the thread in this situation; instead, it erroneously assumes the entire Timer was cancelled. In this case, TimerTasks that are already scheduled but not yet executed are never run, and new tasks cannot be scheduled.

2) What are the valid/strong reasons/limitations of java.util.TimerTask compared to other job scheduler frameworks? So that I myself have a strong belief/reason before choosing a third-party job scheduler framework.

I do not believe Timer facility can be compared with other job scheduling frameworks as it does not provide features that are critical in a typical job scheduling environment. Here is what Flux offers (this is only a subset of the total feature set) :

a) Time and Event based scheduling.
b) Agent/Agentless scheduling.
c) Built-in File monitoring or transfer (FTP, FTP over SSL, SFTP, UNC hosts).
d) Integration with JEE (JMS, EJB, Mail) and Web Services (SOAP, REST).
e) Built-in Error Handling and supports email notifications.
f) Logging and Audit Trail.
g) Web-based Designer, Swing-based Designer.
h) Operations Console (Realtime job monitoring, management and reporting).
i) Built-in Security using JAAS and supports integration with LDAP.
j) Automatic Clustering, Failover, and Load Balancing of Jobs.

For complete feature set, please refer the Flux manual.

3) There are a maximum of 100-200 Users in my application. In case, Users have scheduled reports in such a way at one time there are 100 report requests in the queue. How does the job scheduler framework OR java.util.TimerTask handle such scenarios? Do we have control over this?

In Flux, we have the concept of concurrency throttles which allows users to control how many jobs that can be executed on the Flux engine at any given instant. You can define a concurrency throttle that governs a single Flux instance, or you can define a concurrency throttle that governs all jobs in all Flux instances on your cluster. These coarse-grained concurrency throttles control the parallel execution of large numbers of jobs in one step.

You can also define fine-grained concurrency throttles. For each branch in your job tree, you can define a unique concurrency throttle that governs only the jobs in that branch. More on this can be found in our manual.

4) At any time, Users are allowed to change their report schedules. Does the job scheduler framework support this?

In Flux, this can be achieved either using the Operations Console which allows users to reschedule their job schedule using the web interface or using the Java API programatically. Operations Console provides users advanced monitoring capabilities and it allows users to view jobs as well as pause, resume, remove, interrupt, and expedite them.

5) Obviously, to run a report there are report inputs, that has to be passed to each report schedule. Do we have the flexibility/option in passing parameters to the job scheduler framework?

This is a very common requirement for any job scheduler and Flux supports it using the concept of variable managers (Java API) which allows users to pass parameters to their jobs. Flux also has a neat feature called variable substitution, which can be quite powerful when designing jobs and externalizing certain server specific information (such as host names, credentials, etc) from the job.

6) Which is the best way? Integrating job scheduler framework with web application or running it as a standalone?

Flux supports both the approaches. Quite honestly, it depends on how you would want to leverage the scheduling capabilities within your application. It is a common usecase to embed Flux within applications as Flux provides extensive Java APIs.

It takes less than 5 minutes to setup Flux up and running with an in-memory database. Can you believe that? Give it a try yourself. Let me know what you think.

Possibly Related Posts:

2 Responses to “Job Scheduling in Java, why Flux?”

  • Aravilli

    Hi Arul,

    Can you compare the Flux with Quartz and what other benefits Flux provides over Quartz. That will be interesting to people.