river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: Trunk merge and thread pools
Date Wed, 02 Dec 2015 13:25:03 GMT
Ah. I did not realize that we were discussing a river specific ThreadPool
vs a Java Concurrency classes ThreadPoolExecutor.  I assume that it would
be difficult to just substitute in one of the standard executors?


On Wed, Dec 2, 2015 at 8:18 AM, Peter <jini@zeus.net.au> wrote:

> 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 <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
> 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
> ‚Äč

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