> > > > 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. > > >
we can use ScheduledTask#cancel then will change it and add a flag to go back to previous behavior if desired > > 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> > >> > > > > >
