Analysis on the Cause of timed Task Server restart

Now there is a problem with the scheduled task service. Please check it out: Symptom: the resin of the scheduled Task Server can be restarted occasionally once or twice a day, because when creating a single bean, the Singleton bean is being destroyed. The error classes are runpickuppathservice. the following error is reported before each restart. The log is as follows: caused by: Org. springframework. beans. factory. beancreationnotallowedexception: Error creating bean with name 'transactionmanager ': singleton bean creation not allowed while the singletons of this factory are in destruction (do not request a bean from a beanfactory in a destroy method implementation !) [Info] 15:46:27 info [Resin-Shutdown] org. springframework. Scheduling. Concurrent. executorconfigurationsupport. Shutdown (150) | shutting down executorservice 'taskexecutor'

<! -- Check whether the pick-up path is incomplete and whether replenishment is in. If replenishment is completed, run the pick-up path again --> <bean id = "xw.eckuncompletepathissupplied" class = "org. springframework. scheduling. quartz. crontriggerbean "> <property name =" jobdetail "> <ref bean =" canonical "/> </property> <property name =" cronexpression "> <value >$ {checkuncompletepathissuppliedcron} </value> </property> </bean> <bean id = "xforwareckuncompletepathissuppliedjobdet AIl "class =" springframework. scheduling. quartz. beaninvokingjobdetailfactorybean "> <property name =" targetbean "value =" runpickuppathservice "/> <property name =" targetmethod "value =" checkuncompletepathissupplied "/> </bean> <! -- Run the pickup path for all paths that are not running --> <bean id = "xsarunrunpickuppath" class = "org. springframework. scheduling. quartz. crontriggerbean "> <property name =" jobdetail "> <ref bean =" xsarunrunpickuppathjobdetail "/> </property> <property name =" cronexpression "> <value >$ {rununrunpathcron} </value> </property> </bean> <bean id = "xsarunrunpickuppathjobdetail" class = "springframework. scheduling. quartz. beaninvokingjobdetailfactorybean "> <property name =" targetbean "value =" autorunpickuppathservice "/> <property name =" targetmethod "value =" runallunrunpickuppath "/> </bean>

Targetbean autorunpickuppathservice references the following service, while runpickuppathservice itself is a scheduled Task Service. destory is required when running a scheduled task.

@ Servicepublic class autorunpickuppathservice {private final static logger = loggerfactory. getlogger (runpickuppathservice. class); @ resource private runpickuppathservice; @ resource private xsapickuppathmapper;/*** run the pick-up path for all documents not running the pick-up path, this method is set to scheduled * @ throws exception */Public void runallunrunpickuppath () {synchronized (runpickuppathservice. class) {L Ist <xsapickuppath> pathlist = xsapickuppathmapper. getallunrunpickuppath (); If (null! = Pathlist & pathlist. size ()> 0) {for (xsapickuppath P: pathlist) {try {runpickuppathservice. runpickuppath (P. getserviceno (), true);} catch (exception e) {logger. error ("auto run pickup path error, transfer no:" + P. getserviceno () + "," + E. getmessage ());}}}}}}

 

In this case, the following 1-> 2-> 3-> 4 1. autorunpickuppathservice is running, and only runpickuppathservice is running. 2. After runpickuppathservice is run, it is found that no other classes are referencing itself. Therefore, destroy bean is executed (controlled by spring, destory method is called, and GC is collected if spring is not integrated ). 3. When runpickuppathservice is being destroyed but the destruction is incomplete, the scheduled task autorunpickuppathservice starts to run. Because runpickuppathservice is referenced in the class, the instance of runpickuppathservice is created. 4. Because spring bean is Singleton by default, the above error occurs, that is, Singleton bean creation not allowed while the singletons of this factory are in destruction. The final explanation can be classified into one sentence: mutual calling of scheduled tasks will lead to confusion in the single-instance bean. Solution: remove the call between scheduled tasks. This is the reason for my analysis. The three reboots I detected are all caused by the failure of this scheduled task to create a bean.