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
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
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
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.
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