Re: Trunk merge and thread pools

2015-12-01 Thread Peter
I don't think it will be the case for all situations.   River's thread pool has a requirement that a new thread must be created if none are waiting, even if this results in an oome, which results in an excess of threads being created during load fluctuations, which happens a lot.  Tasks aren't

Re: Trunk merge and thread pools

2015-12-01 Thread Peter
good idea, will do. Sent from my Samsung device.   Include original message Original message From: Bryan Thompson Sent: 02/12/2015 09:46:13 am To: Subject: Re: Trunk merge and thread pools Peter, It might be worth 

Re: Trunk merge and thread pools

2015-12-01 Thread Bryan Thompson
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 ​

Trunk merge and thread pools

2015-12-01 Thread Peter
Completed local merge of trunk into qa-refactor-namespace. Ran qa and regression test suites. Performed some profiling on outrigger stress tests, found blocking queue in org.apache.river.thread.ThreadPool to be a significant hot spot.  Tested all blocking queue implementations, no improvement.

Re: Trunk merge and thread pools

2015-12-01 Thread Patricia Shanahan
Thanks for getting that done. There is a more general message in your thread pool observation. Any time we do something a certain way for performance, we should be prepared for the possibility that the opposite choice will become better in the future. In general, there has been a trend for