river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@marbro.org>
Subject Re: What is wrong with TaskManager?
Date Tue, 09 Apr 2013 09:41:08 GMT
Hi Patricia,

On 4/8/13 4:32 PM, Patricia Shanahan wrote:
> Thanks for the background. The general performance of TaskManager, and
> especially the overhead for runAfter, seemed to me to depend strongly on
> the queue length. For example, a non-trivial runAfter method scans the
> list of tasks older than "this", stopping if it find a collision. That
> is a fast operation for a short queue length. Did you do any
> measurements of that?
> Patricia

Unfortunately I can't provide any meaningful data with regard to queue 
lengths observed. Neither from the plain TaskManager nor the 
ExecutorService implementation where many task submitted through 
TaskManager came together.

Basically this was one of the issues I was never able to finish at that 
time, getting statistics out of a thread pool to make meaningful 
decisions about load factor, min/max size and whether tasks should have 
a dead line. A few times I found out the hard way that being on the 
conservative side I could severely impact the liveliness of the system.

The ExecutorService implementation I referred to was going to collect 
statistics about things as queue length, blocked tasks, execution times 
of task, etc. Hoping these statistics would give as insight in what was 
going on under the hood, or could serve as an alarm for operators to see 
that something could be wrong. That work was never finished though, 
partly because I found it very hard to come up what would be meaningful, 
but in general I came to the conclusion I was willing to sacrifices 
performance over insight what was going on because a thread pool is both 
a blessing and a curse.

Currently I'm in the process of moving my code base to Java SE 8, just 
as an exercise in updating my rusty Java skills and as this is still 
important to me so I might give it another attempt.

Mark Brouwer

View raw message