river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: TaskManager
Date Fri, 01 Jul 2011 02:02:17 GMT
I'm having trouble squaring this with the description of
ThreadPoolExecutor. If I'm reading it right, it *can* be initialized to
set a low limit on the maximum number of threads, but can equally well
be set to have up to Integer.MAX_VALUE threads, effectively unlimited.

There are two forms of TaskManager behavior that I do not see an easy
way to reproduce using a simple ThreadPoolExecutor, runAfter and loadLevel.

runAfter my be better handled by the class issuing the tasks.

loadLevel permits specification of a ratio between threads and tasks, so
that threads are only created up to e.g. one third of the number of
tasks. I'm not sure that is a really good idea. It means leaving tasks
to wait even if we could create another thread.


On 6/29/2011 7:06 AM, Christopher Dolan wrote:
> Just remember, we discussed this a year ago
> (http://mail-archives.apache.org/mod_mbox/incubator-river-dev/201006.mbo
> x/%3C4C12147A.8030601@zeus.net.au%3E) and some of us concluded that
> ThreadPoolExecutor has rather non-intuitive runtime behavior because
> it's optimized to not cause OutOfMemory problems. Not everyone had a
> problem with that behavior, but I'm not a fan.
> Chris
> P.S. can someone add a link to the Incubator mail archives to the web
> page? They are quite hard to find...
>    http://mail-archives.apache.org/mod_mbox/incubator-river-dev/
>    http://mail-archives.apache.org/mod_mbox/incubator-river-user/
>    http://mail-archives.apache.org/mod_mbox/incubator-river-commits/
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Sunday, June 26, 2011 5:18 PM
> To: dev@river.apache.org
> Subject: Re: TaskManager
>> I think the way to look at this is to examine the non-trivial runAfter
>> implementations. If they have common elements that can be helped by
> some
>> utility classes, write those classes. If not, deal with each
>> individually.
>> We are now committed to 1.5, so if we did not have runAfter we could
>> replace TaskManager with java.util.concurrent.ThreadPoolExecutor.
> That's probably where we should be headed, since it reduces our
> maintenance burden.
> Peter.

View raw message