On Jul 7, 2006, at 6:56 AM, Ignacio Silva-Lepe wrote:
I too think that having a work manager implementation that
minimizes dependencies (e.g., Geronimo's)
is a useful thing to have. Wrt using a work manager in the support
for callbacks, we should
just make sure that we are ok with the overall architecture first.
At his point, it looks like the local
case could use a work manager, but not necessarily the remote case.
I am working on a couple of
scenarios (of the technology kind, as Jim refers to them) that
illustrate the main steps so that we can
get a better idea of how the architecture can fit in support for
callbacks in general.
The scenarios there would be a good thing to have.
The goal for the work manager is to have one central place in the
server that coordinates the work that is being done rather than a
collection of independent and potentially competing thread pools.
Whether we use our own or one provided by the host environment would
depend on whether it provided one we could use.
For example, Tomcat manages thread pools inside its coyote connector
and they are designed for dispatching http requests. When combined
with other services that create work (requests) such as inbound JMS
or our own local async there is the potential for physical thread
starvation as each service dispatches independently. This also makes
life harder for the administrator as they need to juggle the sizes of
the different pools.
Projects have started to make their thread pooling externalizable so
that rather than manage the pool themselves they allow things that
are using them to supply one; they just supply a default one. I would
like to ensure that we do the same. That means than when we are
hosted in another environment all work requests can be passed to it
for scheduling on a thread and we get better integration and easier
management.
Depending on the transport we may not be able to do this fully. For
example, if a JMS transport tightly manages its thread pool all JMS
messages may be dispatched to its threads and not through the work
manager. To me, that's an unfortunate limitation of that JMS
implementation that we just need to accept (or choose a different
one, or fix).
So for the remote scenarios, we may not be using the work manager
directly but I hope that we would be able to use it indirectly
through integration with the inbound transports.
Hope that makes sense.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
