Are there any other Java schedulers besides Quartz(FOSS) and Flux(Commercial) - java

I am interested in finding out about other job scheduling packages besides Quartz and Flux. Given the plethora of web frameworks i find it peculiar that there is really only one scheduler. Are there others that perhaps are not as well-known or popular?
SpringBatch: Not really a scheduling solution but rather a batch job coordinator etc.
How does Spring Batch differ from Quartz? Is there a place for them both in a solution?
Spring Batch and Quartz have different goals. Spring Batch provides functionality for
processing large volumes of data and Quartz provides functionality for scheduling tasks.
So Quartz could complement Spring Batch, but are not excluding technologies. A common
combination would be to use Quartz as a trigger for a Spring Batch job using a Cron
expression and the Spring Core convenience SchedulerFactoryBean.

There are others, just not as well known necessarily:
http://java-source.net/open-source/job-schedulers
Also, as I mentioned above, TimerTask can be handy for simple tasks.
But I have to admit Quartz did a great job - it's one of the reasons they were ultimately "bought". jquery is a similar type of well-known solution when you might think there'd be more than there actually are.

Quartz is nice but just an API. Flux is pretty feature rich but more about workflow than hard-code scheduling. Another job scheduling alternative is JobServer with its open source SDK, soafaces. soafaces is a way to build modular server-side java Tasklets. It has lots of scheduling rules and job reporting/monitoring UI stuff also.

Related

Quartz job Vs. Thread for immediate one time task

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

Job scheduling - how to choose the best one for springMVC based application

I am planning to go for Job scheduling for my spring MVC application and while I was searching for the same I came across this. but really don't have idea whether there are many like Quartz or which is the best scheduling API for Spring based application.
I think it really depends upon your requirements. For example:
Do jobs need to survive a restart of your infrastructure?
How critical is the availability of the scheduling framework?
How complex is the type of job you're trying to execute?
Quartz is a dedicated Job scheduling framework and as you would expect comes with many 'enterprisey' features that allow you to build a very highly available, highly performant Job scheduling implementation. It is fairly easy to get started with as well.
Other alternatives could be something like Amazon SQS with again provides a very highly available job queue that operates as a service. However the clue is in the name in terms of 'simple'. You loose a lot of the features that something like Quartz would offer. Amazon do however provide a Java wrapper onto the SQS API so managing it as part of your build should be simple enough.
Alternatively the JDK comes with its own built in options. Take a look at the various implementations of the java.util.concurrent.ExecutorService interface. Again depending upon your requirements there may be something in there that fits the bill without having to depend upon external libraries or APIs.
There is also this list of open-source job scheduling frameworks that should help you to compare other offerings with Quartz.

Divide process workflow between remote workers

I need to develop a Java platform to download and process information from Twitter. The basic idea is to have a centralized controller to generate tasks (id and keywords basically) and send this tasks to remote workers (one per computer). I need to receive an status report periodically to know about the status of both, the task and the worker. I'll have at least 60 workers (ten times more in a near future).
My initial idea was to use RMI but I need to communicate in both directions and I don't feel comfortable with RMI. The other approach was to use SSLSockets to send serialized objects but I would have to control a lot of errors and add a lot of code to monitor tasks and workers. Some people told me about use a framework like Spring Batch, Gigaspaces or Quartz.
What do you think would be the best option for this project? By the time being I've read a lot of good things about Gigaspaces but I don't find a good tutorial about how to implement it and Quartz seems promising. What do you think? Is it worth using any of them?
It's not easy to tell you to go for a technology based on your question. GigaSpaces is certainly up to the job but so is Spring Batch. Quartz is just the scheduling part of your question and not so much the remoting and the distribution of workload.
GigaSpaces is a fully fledged application platform to handle scenario's where parallelism, high throughput and scalability is a factor. Spring Batch can definitely also do the job, but unlike GigaSpaces, it is not an application platform. So you would still need to deploy your application somewhere.
However, GigaSpaces is a commericial product (free version available) but there are other frameworks that can help you such as Storm Project (http://storm-project.net/) and Hazelcast (www.hazelcast.com) also come to mind.
So without clarifying your use case it's hard to give a single answer. It all depends on what exactly you want and how you want to use it, now and in the future.

Schedule a task

Iam using jboss5.1.x, EJB3.0
I need to schedule a task in my application.
which way would you recommend me to do it according to version I am using below?
I heard about SAR, but i am not sure if there is a way which is more appropriate or updated to do it nowdays
thanks,
ray.
I would recommend Quartz
Quartz is a full-featured, open source job scheduling service that can be integrated with, or used along side virtually any Java EE or Java SE application - from the smallest stand-alone application to the largest e-commerce system. Quartz can be used to create simple or complex schedules for executing tens, hundreds, or even tens-of-thousands of jobs; jobs whose tasks are defined as standard Java components that may execute virtually anything you may program them to do. The Quartz Scheduler includes many enterprise-class features, such as JTA transactions and clustering.
Quick Start Guide
I also recommend using Quartz. In case you cannot use it, don't forget the EJB 3.0 standard has the concept of EJB Timer services. You can read more here.
Java EE API javax.ejb.TimedObject supports the feature.
In Java you have TimerTask , you can schedule a task to run at the particular time.But i would recommend Quartz.According to your scenario , you have built in EJB Timer class available , hope will solve the purpose.
Please read this article
http://mhashem.wordpress.com/2010/03/29/java-quartz-scheduler-ejb-3-0-timer-service-and-java-timer-task-when-to-use-each/

Is it possible to run a cron job in a web application?

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.

Categories