Shutdown issues with ManagedScheduledExecutorService

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Shutdown issues with ManagedScheduledExecutorService

This is with TomEE plus 7.0.5

I'm getting /Bean ... has been undeployed/ exception on shutdown, which is
preventing orderly cleanup.  The issue appears to be that a POJO
implementing Runnable is scheduled for periodic execution; that POJO was
created with a reference to a @Stateless bean; and the @Stateless bean is
undeployed before the POJO completes execution.

"Supervisor" is a @Singleton. Supervisor injects, via @Resource, a
ManagedScheduledExecutorService. I don't do any configuration on this
service; I just accept what the container gives me.

"Processor" is a @Stateless bean that does all sorts of work including
entity management, transactions, etc.

Supervisor obtains an instance of Processor via @Inject.

"Runner" is a POJO that implements Runnable. One of its constructor method
accepts an instance of Processor. (as an aside, The run method of Runner
checks for Thread.currentThread().isInterrupted and returns immediately if
true. It also catches InterruptedException (which might be thrown by some of
the blocking methods it invokes), and calls
Thread.currentThread().interrupt() and returns.)

To get the work done on a regular basis, Supervisor creates an instance of
Runner, passing Processor as an argument to its constructor, and then uses
the ManagedScheduledExecutorService to run with fixed delay.  Supervisor
keeps a list of all the Runner tasks it has created.

Supervisor has a stop() method that performs task.cancel(true) on every
Runner task it has created. I have tried, alternatively, annotating the stop
method with @PreDestroy, or explicitly invoking it from a

At shutdown, it looks like Processor is being undeployed before the tasks in
Supervisor are canceled. It appears that the container doesn't know that
Processor needs to be kept deployed while the Runner tasks are still active.

This happens before the Supervisor's stop() method is invoked:

I'm having a hard time reducing this to a test case I can provide.

Sent from: