river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Trunk merge and thread pools
Date Wed, 02 Dec 2015 13:18:15 GMT
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.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Bryan Thompson <bryan@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


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. 


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message