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 object creation and GC to get
more efficient, so that object pooling that improved performance on
early Java versions is a disoptimization now. Still, I'm surprised that
it extends to thread creation.
On 12/1/2015 5:04 AM, Peter wrote:
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.
Wild idea: don't pool threads, create new, let used threads be gc'd
after completion.
Test result; hot spot eliminated, less threads required.
I didn't expect that result.
Hotspot's now serialization.
Going to test jeri mux for graceful degredation under load when oome
occurs next.
Regards,
Peter.
Sent from my Samsung device.
