1) Do you think bindings need to advertise whether they use
non-WorkScheduler threading via the manifest or some other mechanism to
accommodate deployment issues/constraints?
2) Is this what you are saying about direct dispatch?
a) bindings should use WorkScheduler to queue all I/O unless not
possible
b) bindings should dispatch using a scheduleWork call on
WorkScheduler.
c) WorkScheduler right now processes these requests without
constraints
d) direct dispatch could be implemented by modifying scheduleWork to
call the work.run() synchronously
I know I am reading between the lines quite a bit hear, so any
clarification
would be appreciated.
3) Also, is there any way to set quotas using the WorkScheduler? For
example, I created a binding for files, that uses the WorkScheduler to
monitor inbound directories, and I would like to set some limits on how
many inbound files can be dispatched on a single endpoint to prevent one
binding service instance from starving the rest of the system when many
files arrive at once. Now this can be implemented completely in the
binding logic, but it would be nice if worked consistently and
cooperatively across other bindings (i.e., I wouldn't want my binding
starved by the Axis binding or the JMS binding either). This is related
to my question about dispatching.
Quotas could be implemented by modifying the WorkScheduler internals,
but I think we would need a common base class that provides more
information about the work item.
4) If you get rid of the compositeContext, how will unmanaged code do
the locateService?
5) Details on thread affinity:
Suppose I have a legacy transport that I want to create a binding
for.
This transport has thread affinity in that:
a) a message arrives
b) service request executes at application layer
c) application forward request via same transport to another node
If c, does not execute in the same thread as in a, the message
processing cannot be atomic because the commits cannot be coordinated in
different threads of control.
If b executes in a thread other than T1, commit and rollback cannot
be tied to successful execution of the application logic, because the
commit would have to occur before the thread of control transfers.
Does this make sense?
Thanks...PC
-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 12:47 AM
To: [email protected]
Subject: Re: Questions regarding threading related practices
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
