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.
Regards, -- Mark Brouwer
