56
votes

We have a Spring 3 web application on Tomcat 6 that uses several scheduled services via @Scheduled (mainly for jobs that run every night). Now it appears that sometimes (rarely, perhaps once in two months or so) the scheduler thread stops working, so none of the jobs will be executed in the following night. There is no exception or logging entry in our log files.

Has anybody a clue why this is happening? Or how to get more information about this problem?

Is there a way to detect this situation within the application and to restart the scheduler?

Currently we are solving this by having also a logging job that runs every 5 minutes and creates a log entry. If the log file stops being updated (monitored by nagios), we know it is time to restart tomcat. It would be nice to restart the jobs without a complete server restart.

3
What is the work being done in the scheduled tasks? Is it possible that something becomes stuck in an infinite loop? I ask because the scheduled tasks, by default, use a threadpool of 1 thread, and if it gets hung somehow, your future tasks will not be started (but I am sure they would be queued). - nicholas.hauschild
@nicholas.hauschild It calls an external REST webservice. So you are saying that such a request might possibly block (deadlock?) and therefore stop all other jobs. I think I will request a thread dump of the server if this happens again. Thanks for your input. - obecker
Taking a thread dump will probably be a good idea. - nicholas.hauschild
Things to consider 1 - Enforce a timeout on the call to the REST service. Maybe even spawn that call in a separate thread and kill it if there is no response within a specified time. - Steve
Things to consider 2 - Control scheduling from outside your web application. It tends to be more reliable/controllable that way. Maybe take a look at Spring Batch as a means of controlling and monitoring jobs. - Steve

3 Answers

22
votes

Since this question got so many votes, I'll post what the (probably very specific) solution to my problem was.

We are using the Apache HttpClient library to make calls to remote services in the scheduled jobs. Unfortunately there are no default timeouts set when performing requests. After setting

connectTimeout
connectionRequestTimeout
socketTimeout

to 30 seconds the problem was gone.

int timeout = 30 * 1000; // 30 seconds
RequestConfig requestConfig = RequestConfig.custom()
        .setConnectTimeout(timeout)
        .setConnectionRequestTimeout(timeout)
        .setSocketTimeout(timeout).build();
HttpClient client = HttpClients.custom()
        .setDefaultRequestConfig(requestConfig).build();
4
votes

This is pretty easy to find out. You would be doing this with a stack trace. There are many posts on how to get a stack trace, on unix system you do 'kill -3 ' and the stack trace appears in the catalina.out log file.

Once you have a stack trace, find the scheduler thread and see what it is doing. Is it possible that the task it was executing got stuck?

you can also post the stack trace here for more help.

what is important to know is what scheduler you use. if you use the SimpleAsyncTaskExecutor, it will start a new thread for each task, and your scheduling will never fail. However, if you have tasks that don't finish, you will run out of memory eventually.

http://docs.spring.io/spring/docs/3.0.x/reference/scheduling.html

0
votes

In my case stack trace was absolutely clean, thread started only a couple of time and that's all. The problem was in conflict with another schedule.

Updated

Schedule not work correctly, because I use fixedDelayString and the previous job not ended when was time to start new. After changed schedule to fixedRateString, threads started correctly.