river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: TaskManager
Date Wed, 29 Jun 2011 14:06:02 GMT
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.

Mime
View raw message