Hi Peter,
Comments inline...
Jim
On Oct 16, 2006, at 7:39 PM, Peter Cousins wrote:
What is considered the best practice for propagating classLoader and
compositeContext across threads? For example when a binding
dispatches
to a service, should it be copied from the thread that initialized the
binding to the thread where the binding dispatches? For example, the
Axis binding propagates the classLoader before the service dispatch.
Should the WorkScheduler propagate either of these to the work items
that it runs?
As a general rule of thumb, a binding should not create threads of
its own but instead use the WorkScheduler service. Of course, some
bindings may insist on creating their own thread (e.g. it uses a
library that does so without any hook points for supplying a thread
factory).
In terms of propagating context, the WorkScheduler will not know all
of the context that needs to be propagated, particularly for policy
information such as security. I think we will need to have
interceptors which know how to propagate specific context information
by placing it in the Message. For example, in a non-blocking wire
consisting of an outbound/inbound interceptor chain pair, there would
be interceptors on the outbound side that would place context in the
Message flowing through the wire. After the outbound chain is run,
there is a NonBlockingInterceptor that uses a WorkScheduler to
continue the dispatch to the inbound chain on another thread. After
the request is dispatched on the other thread, the inbound chain on
the other end would have interceptors that pulled the context from
the message and set it up. We will probably need a similar thing for
bindings since a particular binding may not know all context
information flowing through it.
I'm praying CompositeContext goes away from the spec (Jeremy and I
are going to start a campaign to remove it) so hopefully we won't
need to deal with it :-)
Is there any infrastructure in place for allowing a binding to decide
whether queued dispatch or a direct dispatch is more appropriate? A
couple examples of what I mean:
* It would be nice to direct dispatch and avoid the context switch if
the system throughput is sufficient to prevent a backlog, but
otherwise
the main consideration is accepting inbound work requests until some
high water mark is reached. This case benefits greatly from a
mechanism
to coordinate across bindings.
We could potentially build this into the WorkScheduler service
although I would prefer to do this when we need it as opposed to
upfront.
* Some bindings may require the dispatch to occur in the same
thread of
control as the binding due to legacy transaction issues that have
thread
of control affinity. Does anything need to be done to communicate
this
requirement to the rest of the framework so a request doesn't get
swapped to another thread by another component in the chain of
command.
This is interesting. Could you provide more specifics? This seems
like it can get very complicated, very quickly. For example, if I
understand correctly:
Service 1------
\
---------> Component A------->Component B
Service 2-----/
Both Service 1 and Service 2 are wired to a sevice on Component A. If
I follow what you are saying, Service 1 could have a "legacy
transaction issue" that requires the request be dispatched on the
same thread as it flows to Component A and then Component B. Service
2 does not have that restriction. One of the issues I see is if
Component A is wired to a non-blocking service on Component B, then
how would the dispatch be done in a non-blocking fashion without
using another thread? If the request come in over Service 2, non-
blocking behavior further on would be allowed.
I think we could draw up a similar scenario using references:
Component A------->Component B--->Reference 1
Where the invocation from A to B is non-blocking.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
