Paul Hammant wrote:
>
> >
> >
> >For the moment but the long-term strategy would be to move everything to use
> >block directly rather than ThreadContext.getThreadPool(). The main reason is
> >because that matches how we use it and it would be easier to manage
> >performance characteristerics of pool that way.
> >
> I'm intrigued. You see multiple implementations of threadpool don't you..
Can you make it a simple Component instead of a Block?
I want to be able to use the Thread Pooling in places where Blocks can't be
compiled/used. For instance, Cocoon has a few locations where it spawns a
background thread--that really should be managed by a Thread Pool. Also,
in the absence of an *official* Thread Pool implementation, JdbcDatasource
and ActiveMonitor spawn their own threads--when they really need to use the
Thread Pool.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
