----- Original Message -----
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> AFAIK, replacing the abstraction could require decoupling the handler
> classes entirely from Avalon Frameworks. ....
> why would we want to decouple from Avalon now?
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.
I guess if thread library is stable in Avalon there is no need to make that
effort. I have been out of Avalon lists for a long time, but it was my
impression that there have been on and off threading issues. It would have
been better to have relied on a standard threading library because it is
hard(at least to me) to get an optimal combination of correctness and
performance in mutilthreaded code.
The general philosophy I was trying to suggest is this - get best of breed
and plugin, while maintaining the same abstractions. Trim or suggest to
Avalon folks a narrowing of abstraction from James experience.
[hb]
> > can you point out where the thread pool finally changes have been done.
> > Can't see from the diffs and how this is a problem with current system.
[noel]
>
> finally {
> Thread.currentThread().interrupted();
> }
>
> Technically, Thread.interrupted() would suffice; currentThread() is
> redundant.
Wow, relying on Thread#interrupted to clear interrupted state. It must have
been a huge effort to find this workaround. Would this be needed post
threading fixes in Avalon ?
Harmeet
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
