Quartz Study Record 1

Reason

The company has some batch timing tasks that may need to be performed at night, using the Quartz and spring batch two frameworks. Quartz is a timed task framework, and spring batch is a batch framework.

Although my own gadgets usually do not need to be scheduled tasks, but I think this framework is quite interesting, so it is intended to study a bit. Record share my study record.

In addition to some of the online timing task of the time cron How to configure what I do not introduce ... Bad street ... I'll just talk about my understanding.

Integration with spring

There may not be any place to use spring now. Spring and quartz integration is slow and simple ... Just configure the 2 beans to be OK.

The structure of my project is this:

The main thing is:

1. Introduce quartz-context.xml this configuration in Application-context.xml. (Application-context is the Contextloadlistener read configuration of Spring)

2. In Quartz-context.xml, 2 beans are configured, and the first Bean Scheduler the Scheduler Bean. He has some properties that can be configured, such as my configured Configlocation and Autostartup. Other properties can see for themselves what the properties of this class are ...

The second bean is trigger, which is the trigger. The most important attribute in him is jobclass. Is the type of your scheduled task.

3. Write a bean extends Quartzjobbean yourself. To achieve his executeinternal method can be.

According to my current understanding is the scheduler as long as it is to read some of the user's configuration, generate some trigger. Each trigger can trigger its own configured jobclass. Then we wrote the Jobclass to do the specific thing.

Because I do the tests on my own, there are only 1 scheduled tasks. So I only have 1 trigger.

It's more clear and simple ... In addition: Some sayings on the internet can be used without inheriting quartzjobbean, with additional jobdetail ( Org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean) on the line.

Basic Configuration and logic

After just the configuration of the scheduled task will be able to run up. But as a beginner, I still have some questions.

What properties can I configure in quartz.properties?

Yes, in front of the Schedulerfactorybean introduced the quartz.properties, then this file is some quartz configuration. Just like hibernate's. cfg file. What can be written in this properties?

First, let's take a look at the Schedulerfactorybean class name, The full name is Org.springframework.scheduling.quartz.SchedulerFactoryBean. from which we can see that this is spring and quartz integration, he is a factorybean, So the bean that is configured in XML is actually the object that is obtained by invoking its GetObject method, Whether it's from debug or the class name to guess. We can all find it easily. The generated bean should be org.quartz.impl.StdSchedulerFactory. Look at the class name again. Org.quartz. Well... That's right... This is Quartz's own core class when there is no integration of spring.

Then, if you have more experience, you may think of this kind of factory class, usually read a bunch of configuration files, and then generate a panel class for the user (it is time @hibernate sessionfactory and session, This is a summary of my own current.). Quartz should be the same. The parameters that can be configured in Quartz are basically written in the Stdschedulerfactory class.

But not all, note that there are some. class, such as quartz the default threadpool is Simplethreadpool.

Then you have to configure the number of his initial threads to be set to

12 org.quartz.threadpool.threadcount:15

So ... Because Simplethreadpool has a Setthreadcount method ....

If we are not experienced, we can not see from the member domain that these are configurable ... Then we can also see some clues from Debug.

Schedulerfactorybean is the implementation of the Initializingbean interface.

458 rows We can see that the generated factory is Stdschedulerfactory

And 459 lines is the initialization of this generated Stdschedulerfactory,schedulerfactorybean in the configuration of some stdschedulerfactory default properties

And then 480 lines behind (I don't have a truncated complete) This.scheduler = Createscheduler (schedulerfactory, this.schedulername);. Stdschedulerfactory's instantiate method is called when Schedul is obtained through Stdschedulerfactory, Various configurations are initialized here. The method is too long. I won't post it. From the instantiate method we can also see which configurations are used.

For example, I configured

1 org.quartz.threadpool.threadcount:152 org.quartz.threadPool.threadNamePrefix = haha 3 org.quartz.scheduler.threadName = Jyz

The effect is this:

Isn't it fun ...

Look at the configuration. I also thought of a problem: if the number of scheduled tasks too much more than the default number of threads, it will continue to trigger?

The problem is that it is similar to the data source. If Init has 5 database links, now you want 6 links, are you adding links based on maxactive or how?

It seems like you didn't see a similar configuration from Simplethreadpool .... Only one threadcount can set the number of initialized threads ... I tried it myself, the same Jobclass task 1 seconds to print one output at a time, but thread.sleep12 seconds before the output. The discovery does not add a thread, that is, the first 11 seconds and the 12th second nothing happened ... (Quartz the number of threads generated by default is 10) ... This is a little awkward ... Do not know is to set threadcount big point ... Or should I go to realize the org.quartz.spi.ThreadPool ... (Although I think it's a little bit bigger.)

If the next time the scheduled task is not over, will it continue to trigger?

First look at the Jobclass configuration is a class. So we can see that our specific job class object should be generated with reflection, that each generation should be a different instance, even if the previous time did not run out will not affect the next execution.

If you use Methodinvokingjobdetailfactorybean in front of you, there is a concurrent property that can be set for concurrency, which is true by default.

You can lock yourself up if you like me. This is my current solution. But if I locking myself, that thread is still occupied. So if the timing of the task is more awkward. (although this does not seem to be the case in general)

How to inject spring beans

Because the front job class should be reflection-generated and not managed by spring, So it is not possible to inject spring objects. But Triggerfactorybean and Schedulerfactorybean are the spring beans we've configured. Some of the context properties (map types) can be configured, We should be able to get this information through the context in the Executeinternal (Jobexecutioncontext context) of the specific job we are writing. There is a way to introduce on the Internet, but I did not look closely.

I think the simplest thing is to write a tool class directly, inheriting spring's applicationcontextaware. You can then use this tool class to get ApplicationContext to get the service or other beans you want. It seems to be a little simpler than the previous XML configuration.

The above is my beginner quartz feeling

Quartz Study Record 1