I already asked a separate question on how to create time triggered event in Java. I was introduced to Quartz.
At the same time, I also google it online, and people are saying cron in Unix is a neat solution.
Which one is better? What's the cons and pros?
Some specification of the system:
* Unix OS
* program written in Java
* I have a task queue with 1000+ entries, for each timestamp, up to 500 tasks might be triggered.
Using cron seems to add another entry point into your application, while Quartz would integrate into it. So you would be forced to deal with some inter-process communication if you wanted to pass some information to/from the process invoked from cron. In Quartz you simply (hehe) run multiple threads.
cron is platform dependent, Quartz is not.
Quartz may allow you to reliably make sure a task is run at the given time or some time after if the server was down for some time. Pure cron wouldn't do it for you (unless you handle it manually).
Quartz has a more flexible language of expressing occurences (when the tasks should be fired).
Consider the memory footprint. If your single tasks share nothing or little, then it might be better to run them from the operating system as a separate process. If they share a lot of information, it's better to have them as threads within one process.
Not quite sure how you could handle the clustering in the cron approach. Quartz might be used with Terracotta following the scaling out pattern (I haven't tried it, but I believe it's doable).
The plus for cron is that any sysadmin knows how to use it and it's documented in many places. If cron will do the job then it would really be the preferred solution.
Related
Let's say I have some unit of work that needs to get done and I want to do it asynchronously relative to the rest of my application because it can take a long time e.g. 10 seconds to 2 minutes. To accomplish this I'm considering two options:
Schedule a Quartz job with a simple trigger set to fire only once and as soon as possible.
Create a Runnable instance, hand it off to a Thread, and call run();.
In the context of the above I have the following questions:
What does using the Quartz job get me that the thread doesn't have?
What does using the runable get me that using the quartz job doesn't?
In terms of best practices, what criteria ought be used for deciding between Quartz jobs and runnables for this use case?
With Quartz you have many features "well implemented", like:
transaction mgmt of job execution
job persistence, so that we know the status of the running jobs
clustering supports
scheduling control, even if you just need the simple trigger. But it provides the possibility.
without using it, you have to control them on your own, some issue could be complicated.
Starting new thread:
light weight no job persistence, quartz api etc.
your application runs without extra dependency (quartz)
error source (from quartz) was reduced
It depends on what kind of job do you want to start, and if other features of your application require job scheduling too.
If your concern is just asynchronisation, you can just start a thread. If there were other concerns, like clustering, you may consider to use quartz.
I would not add Quartz to a project just for this capability, but if I already had Quartz installed and was already using it, then, yea, even for a one off I would use a one time immediate Quartz job.
The reason is simply consistency. Quartz already manages all of the details of the thread and job process. A single thread is Simple, but we also know from experience that even a single thread can be Not Simple.
Quartz wraps the thread in to a high level concept (the Job), and all that which it brings with it.
From a code base point of view you get the consistency of all your jobs having the same semantics, your developers don't have to "shift gears" "just for a thread". Later, they may "just do a thread" and run in to a complexity that Quartz manages painlessly.
The overhead of the abstraction and conditions that make a Quartz job are not significant enough to just use a thread in this case because "it's lighter weight".
Consistency and commonality are important aspects to a codebase. I would stick to the single abstraction and leverage as much as I can.
If it's a one-time job and there are no additional requirements, like job persistency, scheduling, etc. then you're better off with regular threads.
Quartz jobs are much more robust than regular threads and support scheduling, job persistence, etc., all the other stuff that you probably don't need.
No need to set anything up with Runnables and Threads
If you think there might be more jobs that this, scheduled jobs, delayed jobs, etc, you have 2 options: go with Java's standard Excecutors. Set up a thread pool and use this to run your jobs. You might also want to use Spring's TaskExecutor abstraction so you can easily switch between Quartz and Executors when you need it. But that seems like an overkill for a one-time gig.
For immediate 1 time task, Threads will be enough.
But there are better plugins available like quartz, Spring Scheduler
I am want to distribute a jar script that needs to run periodically. I don't know which OS the end user will have.
Is there a cross OS solution that I can use to run a jar file at a specific time each day.
That is, in windows it adds a scheduled task and a cron task etc.
Any help appreciated !
You could use a task scheduling framework written in Java, for guaranteeing portability across OS - because each OS has its own scheduling commands, you won't find the same tools across different platforms.
For instance, take a look at Quartz. But be warned, you'll have to learn how to configure, setup and program tasks with it, IMHO it's not that simple. But then again, that's the price you have to pay for portability.
Yet another option would be to schedule a task using a Timer service (take a look at the tutorial), but for that you'll need a Java EE compliant server. Either way notice that "running a jar" really means executing the main method in the jar file, which is just a call to a Java program.
If you are looking for OS independent scheduler, such a thing does not exist. Quartz is a task scheduler for java environment. For example - you can use quartz to schedule tasks in your java program. You have to write a java program and keep running it all the time for using quartz for your requirement. In other words, you have to start your java program when the OS boots up so that it is ready to run your scheduled job. Too much complexity for the task at hand! You should consider using OS specific scheduler for your need.
In a java web application (servlets/spring mvc), using tomcat, is it possible to run a cron job type service?
e.g. every 15 minutes, purge the log database.
Can you do this in a way that is container independent, or it has to be run using tomcat or some other container?
Please specify if the method is guaranteed to run at a specific time or one that runs every 15 minutes, but may be reset etc. if the application recycles (that's how it is in .net if you use timers)
As documented in Chapter 23. Scheduling and Thread Pooling, Spring has scheduling support through integration classes for the Timer and the Quartz Scheduler (http://www.quartz-scheduler.org/). For simple needs, I'd recommend to go with the JDK Timer.
Note that Java schedulers are usually used to trigger Java business oriented jobs. For sysadmin tasks (like the example you gave), you should really prefer cron and traditional admin tools (bash, etc).
If you're using Spring, you can use the built-in Quartz or Timer hooks. See http://static.springsource.org/spring/docs/2.5.x/reference/scheduling.html
It will be container-specific. You can do it in Java with Quartz or just using Java's scheduling concurrent utils (ScheduledExecutorService) or as an OS-level cron job.
Every 15 minutes seems extreme. Generally I'd also advise you only to truncate/delete log files that are no longer being written to (and they're generally rolled over overnight).
Jobs are batch oriented. Either by manual trigger or cron-style (as you seem to want).
Still I don't get your relation between webapp and cron-style job? The only webapp use-case I could think of is, that you want to have a HTTP endpoint to trigger a job (but this opposes your statement about being 'cron-style').
Generally use a dedicated framework, which solves the problem-area 'batch-jobs'. I can recommend quartz.
How can I run a task daily at a specified time (say 11:00 am) using java.util.Timer? I'm using JDK 1.4.2, I know it's old, but it's what the project requires.
Quartz is the most well known solution to schedule processes in Java environments, but you have a lot of options. Check this list:
Quartz is an open source job scheduling system that can be integrated with, or used along side virtually any J2EE or J2SE application. Quartz can be used to create simple or complex schedules.
Jcrontab is designed to be extended and integrated with any project. Reads and stores the tasks to execute in a file, a database or an EJB and provides a web UI and a basic swing GUI.
Essiembre J2EE Scheduler is a simple task scheduling mechanism for J2EE applications. This library can be considered a wrapper around the Timer and TimerTask classes found in the standard Java API. Configuration for tasks to be executed and their frequency is XML-based.
cron4j is a scheduler for the Java 2 platform which is very similar to the UNIX cron daemon.
Oddjob's goal is to provide some order and visibility to all the batch files and cron jobs that tie an enterprise's critical business processes together.
Fulcrum Scheduler provides a scheduler service. It is based on the TurbineScheduler provided with Turbine, but all older stuff has been removed. Currently ONLY the non persistent Scheduler is done. It loads scheduled jobs from the component config xml file.
Gos4j -Goal Oriented Scheduling for Java- is a way of organising processing priorities based on goals.
Job Scheduler is a batch program operating as a demon, and can be controlled using a graphical user interface. The Job Scheduler uses an XML configuration for the scheduled programs, scripts and for the timing and frequency of task processing. An API is available that hands control of events and logging to your jobs.
JDRing is a lightweight Java scheduling library that is simple and small, but still supports ringing alarms at specified intervals, as one-time events, or on complex schedules with full cron-like control.
jBatchEngine is a batch job spooler written in Java. In constrast to time driven schedulers like Cron, jBatchEngine is event driven.
MyBatchFramework is an open-source lightweight framework designed to create easily robust and manageable batch programs into the Java language.
Super with SuperScheduler and SuperWatchdog is a Java job scheduler with rich GUI for all applications. It is platform neutral. Especially good to be a job scheduler for Linux and Solaris. It provides a super set of functionalities of the Scheduler of Microsoft Windows. It provides event-triggered scheduling. It can schedule tasks in a distributed environment. A task will be executed once and only once among all machines in the network. All tasks are holiday adjustable. Even every job is a STANDBY job, the history will be a good trace for important tasks. It supports Internationalization.
source: Open Source Job Schedulers in Java
Look into TimerTask and Timer - both are in that version of the JDK.
Timer :
public void schedule(TimerTask task, Date firstTime, long period)
public void scheduleAtFixedRate(TimerTask task, Date firstTime, long period)
Set it to run the first Date you want then the number of milliseconds in one day as your delay.
Is it possible for you to use a library such as cron4j? It will make your job much easier!
Java Timers can run an arbitrary job at intervals, pre-fixed times, etc.etc.
Quartz library
If you really want to be bare-bones about it, wrap it in a shell script and put in in cron.
You have to use Quartz
I have never know who launches Quartz in first place though.
If you have an application server or similar artifact you can configure the Quartz job there and have it run your task at the given time.
Maybe, that recent post helps you:
Will this pause my Java thread for a minute?
My response for that question is use a java built in implementation based on java.util.Time and java.util.TimerTask classes:
Will this pause my Java thread for a minute?
Or, you can use the crontab service for *nix platforms (available for Windows platforms too). That's the simplest and light-weight style to run a standalone job periodically.
[]'s,
And Past
I'm drawing a design for a system to do daily business functions for my company. It will consist of a Oracle 10g database with Pl/SQL packages and a Java-based web application. All of this is running on a Solaris 10 server. Aside from handling transactions from the web interface, scheduled tasks need to run on the database to run calculations and load data etc.
This is a redesign of a legacy system that currently controls everything with a plethora of cron jobs. Given the task of redesigning it, would you do it differently? I know Oracle has its own task scheduler, but the DBA argues that he would rethink using it because if the database is down or offline for some reason, it can't send alerts or log errors of any kind. The cron jobs currently have the ability to send SMS messages or emails should one of the tasks fail. Another option would be to have the web application do it somehow.
What do you suggest?
Are all the scheduled tasks related to the database? If so, then your DBA's objection is irrelevant: you don't want to run the jobs when the database is offline for planned downtime, and the DBA ought to have something in place to alert them if the database is down for unplanned reasons, rather than relying on a signal from a failing cron job.
If you have jobs which run on other parts of the architecture without touching the database then certainly an external scheduler makes sense. There are plenty of commercial products, but if you want to go for FOSS then you probably ought to look at Quartz.
Having used both cron and the Oracle job scheuler - I have always found it a lot more reliable and easier to user and understand cron. It has more things that it can do (interface with the entire OS, not just Oracle). I would choose cron.
My rule of thumb for scheduled jobs is consistency. Since you've already got a lot of infrastructure in place like alerting I'd stick with cron.