I'd like to use quartz in a project of mine. I know that there is a scheduler and a threadpool for the jobs.
Does the scheduler continuously run in its own thread and fires off the jobs?
If I run the app on a 2 core CPU will one core be busy with the scheduling thread?
Yes, quartz uses at least n+1 threads where 1 is the scheduler thread that is running in an infinite loop sleeping before next task that should be triggered. N is the number of worker threads in the threadpool. You can configure this number using the property org.quartz.threadPool.threadCount.
You can see it work by running the stuff through for example Eclipse and then in the debug view you can see the active and sleeping threads of the application.
Quartz will create a configurable pool of threads. Each job will fire in its own thread (of course, otherwise they can't run concurrently). And no, its not a busy loop so the scheduler won't claim a CPU for itself.
Related
Can an Executor run multiple tasks on a single thread?
Obviously the task execution cannot happen simultaneously with only one physical core to run on, but is there a way to wait or yield so the other submitted tasks can run?
If there is not a wait then how else can one determine, generally, when the other task will run?
Yes.
Not with the current implementations.
No.
;)
Consider the documentation on SingleThreadExecutor (http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html#newSingleThreadExecutor()), and Wait between tasks with SingleThreadExecutor on StackOverflow.
You could implement your own thread-sharing lock between threads, and run them on a multi-thread executor... but if you want someone else's implementation to do that, well, as far as I know, you're out of luck.
I have 56 jobs scheduled as cronTrigger, all at an exact same time.
I expect these jobs all start executing together, without having any sequence.
like each one executing in it's own Thread. however quartz scheduler executes them one by one.
I did some research, and found this
Quartz Thread Execution Parallel or Sequential? that suggest setting of following properties in quartz.properties file:
org.quartz.scheduler.batchTriggerAcquisitionMaxCount = 60
org.quartz.threadPool.threadCount = 60
sad to say, it didn't work for me. still when one of my jobs encounters an exception, it keeps trying to run the job, which is fine, but other jobs never execute until this one totally fails after some attemps.
Do you know how to make the scheduler to exhibit a parallel behavior?
Thanks.
I am using Sling's scheduler to schedule periodic jobs and I'm wondering if I'm scheduling job A to run every 5 minute. In the unlikely occasion, the job start to run and took more than 5 minute what will happen? I have specified the job cannot run in parallel.
Job A will run again immediately after the previous run finishes.
Job A will run 5 minute after the previous run finishes.
Under the hood, Sling's scheduler is using QuartzScheduler, so if you know how QuartzScheduler will behave in this case please do share your knowledge as well.
Any help is much appreciated!
In Quartz Scheduler 2.1.x the annotation DisallowConcurrentExecution is used to prevent concurrent execution of the same Job.
In Quartz Scheduler 2.0.x in order to void the concurrent execution of a Job you have to implement the StatefulJob interface.
The decision on whether the misfired execution will execute when the previous job completes or it will be ignored depends on the trigger's misfire policy. By default when the scheduler starts, it searches for any persistent triggers that have misfired, and it then updates each of them based on their individually configured misfire instructions.
So in my opinion Job A will run again immediately after the previous run finishes. I suppose that Sling uses the default misfire policy. Otherwise the answer depends on the misfire policy selection.
That's how Quartz Scheduler works. I don't know how the Sling's scheduler works.
I hope this helps.
is Eclipse 3.0 Jobs API using any internal thread pool for executing jobs?
or is it creating a new thread each time a job is scheduled (about to be started)?
if it doesn't use any thread pooling, is it somehow possible to use Jobs with Java's ExecutorService so that scheduled jobs will reuse existing threads from the Executor's pool?
if not then last question, is there a chance to provide progress feedback in the Eclipse progress view (as I'd do with Jobs IProgressMonitor) but from within a regular Java Thread?
I really like the features Jobs API provides (especially progress monitoring and cancellation) but I'm a bit concerned about the overhead it may introduce to the main UI thread if it doesn't use thread pooling and the jobs are scheduled really often.
thanks in advance!
regards,
jb.
Eclipse Jobs do use a fixed number of worker threads. Jobs are allocated to these worker threads, based on the priorities.
I cannot find any documentation stating that, but if you start your Eclipse instance in debug mode, you can see some worker threads in the thread list - these are the threads jobs are executed in.
I am using visualVM to monitor my java program, started within eclipse.
I am using quartz scheduler and have 2 worker threads, so there are 3 threads for quartz.
I have another thread running listening to a socket.
Then I have a thread pool with 50 threads.
But it shows there are total 164 live threads with 110 are deamon threads.
I saw there are dataStreamer. Does java have a thread to handler data stream?
I also saw there are many PesponseProcessor for block blk_...
What does those threads response for, and witch kind of block it point to?
Please note VisualVM will launch 5 threads of his own for the RMI communication and serialization of thread dumps. You can completely ignore those.