The trick is we need to rely on shutdown() being called when the bean is undeployed to ensure the application can successfully terminate and not leak timers.
Sharing a ScheduledExecutorService per application is the best we could do in that regard. The shutdown logic would still become a bit difficult as would the Stateless container logic. The StatelessInstanceManager which builds the pool would also have to build the ScheduledExecutorService and pass it in, track the ScheduledExecutorService in the ApplicationContext or ModuleContext and clean it up on undeploy. The StatelessInstanceManager would have to be careful not to create the ScheduledExecutorService more than once per app or destroy it more than once per app. The pool class would need to remain generic (not specific to stateless beans) and still be prepared to construct a ScheduledExecutorService if one wasn't passed in. Similar to what it does now for the regular Executor service. -David On Fri, Jun 12, 2015 at 8:25 AM, Romain Manni-Bucau <[email protected]> wrote: > Hi guys, > > already got this issue and Mark pinged me about it yesterday. ATM we have 1 > eviction thread by stateless instance manager (pool). So if you have 100 > stateless beans you then have 100 threads doing nothing. > > Do we want to reduce it to N fixed threads (default to 3 maybe?) per > stateless container (but multiple tasks to keep access timeout and close > timeout respected)? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> >
