SpringJobExecutor cannot be shutdown and started up.

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

sangv

Hey Guys,

I wanted to understand this before I create a defect. Recently, I moved to using the SpringJobExecutor and found that I could not shut it down and restart it without booting up the process engine again. Ofcourse, I was experiencing this in my unit tests ( jobExecutor.start() in the setup method and jobExecutor.shutdown() in the teardown method) but wanted to understand the expected behavior.

/** From SpringJobExecutor **/
@Override
protected void stopExecutingJobs() {
stopJobAcquisitionThread();
taskExecutor = null;
}‍‍‍‍‍‍

 

I believe the developer (Pablo) that worked on https://jira.codehaus.org/browse/ACT-1258 was following the pattern in the DefaultJobExecutor

/** From DefaultJobExecutor **/
protected void stopExecutingJobs() {
    …
    threadPoolExecutor = null;
  }‍‍‍‍‍

But the difference is that the DefaultJobExecutor instantiates  a new threadPoolExecutor  programmatically in its startExecutingJobs()

/** From DefaultJobExecutor **/
protected void startExecutingJobs() {
    …
    if (threadPoolExecutor==null) {
     threadPoolExecutor = new ThreadPoolExecutor(corePoolSize, maxPoolSize, 0L, TimeUnit.MILLISECONDS, threadPoolQueue);     
      …
    }
    startJobAcquisitionThread(); 
  }‍‍‍‍‍‍‍‍‍

Here are my questions:

i) Why are we setting the ThreadPoolExecutor to null in the stopExecutingJobs() method in the DefaultJobExecutor?

ii) Considering that there is a good reason for i), does the same reason apply to SpringJobExecutor? I don't like that we are resetting a spring injected taskExecutor to null through code. This is not intuitive and took me some time to get to.

iii) I would like the jobExecutor to be working as expected it has been shutdown and started again. I would recommend that we should not set the taskExecutor to null in the stopExecutingJobs() method. Optionally (and less preferably), we could also set a new TaskExecutor in the SpringJobExecutor's startExecutingJobs method. Thoughts?

Thanks,
Sang

frederikherema1

I think this is a problem that grew historically. In the beginning, the threadPoolExecutor was not configurable but rather always created internally, using the passed in params for max/core pool sizes. A default ThreadPoolExecutor cannot be started again/reused after shutdown, AFAIK. When the spring-implementation was added, the existing behavior was not altered, rather just built upon.

So you're absolutely right about the fact that (especially in spring-case) it makes no sense to set the executor to null, since it's injected at the beginning, rather than created. The main problem is that the TaskExecutor interface has no start/shutdown methods available, so explicit start/shutdown of the executor is in spring's hands. Now that I look into this, the current implementation (setting task executor to null) doesn't have any effect and cannot guarantee that no jobs will be executed (which were in the executor queue) after job-executor was shut down.

I'll remove the taskExecutor = null call from the codebase…