+1 The number of system properties keeps increasing and I'm sometimes lost myself. Don't have a lot of solutions to propose, but probably it's time to find something more sane.
just my 2 cts -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Jun 15, 2015 at 8:21 PM, Mark Struberg <[email protected]> wrote: > > > > 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. > > 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> > >>>> > >>> > >>> > >> > >
