> I was not suggesting we decouple. I was suggesting that we implement the
> ThreadPool Manager abstraction using util.concurrent at least the part of
> ThreadPool abstraction that James uses.
We'd have to replace the DefaultThreadManager block. My concern is that
without auditing the code, I don't know, a priori, that we wouldn't
introduce new problems by mixing and matching between util.concurrent and
Excalibur. Avalon is already planning a JSR 166 pickup, and James is
currrently running OK with their code.
> > finally {
> > Thread.currentThread().interrupted();
> > }
> Would this be needed post threading fixes in Avalon ?
Probably not, but why not clean up after ourselves? If we did replace the
ThreadPool implementation, what requirements might it have? This is a good
issue tidbit to raise with the JSR 166 folks. There ought to be a defined
semantic for working with thread pools. Either Runnables have to catch
exceptions and clean up, or they don't. For example, Commons ThreadPool (in
their sandbox) says that "inside the run() method of your Runnable object
you must handle Exceptions properly." The docs don't mention other thread
state issues.
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
