Just remember, we discussed this a year ago (http://mail-archives.apache.org/mod_mbox/incubator-river-dev/201006.mbo x/%3c4c12147a.8030...@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:j...@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.
