Ah. I did not realize that we were discussing a river specific ThreadPool vs a Java Concurrency classes ThreadPoolExecutor. I assume that it would be difficult to just substitute in one of the standard executors?
Bryan On Wed, Dec 2, 2015 at 8:18 AM, Peter <j...@zeus.net.au> wrote: > First it's worth considering we have a very suboptimal threadpool. There > are qa and jtreg tests that limit our ability to do much with ThreadPool. > > There are only two instances of ThreadPool, shared by various jeri > endpoint implementations, and other components. > > The implementation is allowed to create numerous threads, only limited by > available memory and oome. At least two tests cause it to create over > 11000 threads. > > Also, it previously used a LinkedList queue, but now uses a > BlockingQueue, however the queue still uses poll, not take. > > The limitation seems to be the concern by the original developers that > there may be interdependencies between tasks. Most tasks are method > invocations from incoming and outgoing remote calls. > > It probably warrants further investigation to see if there's a suitable > replacement. > > Regards, > > Peter. > > Sent from my Samsung device. > Include original message > ---- Original message ---- > From: Bryan Thompson <br...@systap.com> > Sent: 02/12/2015 09:46:13 am > To: <dev@river.apache.org> <dev@river.apache.org> > Subject: Re: Trunk merge and thread pools > > Peter, > > It might be worth taking this observation about the thread pool behavior to > the java concurrency list. See what feedback you get. I would certainly > be interested in what people there have to say about this. > > Bryan > > >
