Probably worth it waiting to hear from David. I know he spent some significant time re architecting the stateless pool.
There were probably some reasons we may not know. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Fri, Jun 12, 2015 at 9:10 PM, Romain Manni-Bucau <[email protected]> wrote: > Le 12 juin 2015 20:55, "Adam Cornett" <[email protected]> a écrit : > > > > Would it make sense to have the pool size scale up automatically with the > > stateless bean count at an adjustable ratio and a hard floor of 3 or so > > threads? > > Hmm maybe i get it wrong but the idea is to prevent it to scale/increase > thread count > > > On Jun 12, 2015 2:45 PM, "Mark Struberg" <[email protected]> wrote: > > > > > +1 Think that makes it also easier to debug and maintain. The current > > > approach simply doesn’t scale well in big deployments. > > > > > Well it does but thread dumps are a pain and it is useless > > > > LieGrue, > > > strub > > > > > > > > > > Am 12.06.2015 um 09:25 schrieb Romain Manni-Bucau < > [email protected] > > > >: > > > > > > > > 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> > > > > > > >
