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
