Le 15 juin 2015 20:21, "Mark Struberg" <[email protected]> a écrit : > > > > > will change it and add a flag to go back to previous behavior if desired > > Side note on that: sometimes it makes sense to create switches to switch back to custom behaviour. But our code becomes increasingly hard to maintain that way.
Well here it is really literally 3 lines > > LieGrue, > strub > > > Am 15.06.2015 um 20:26 schrieb Romain Manni-Bucau <[email protected] >: > > > >> > >> > >>> 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> > >>>> > >>> > >>> > >> >
