Questions regarding threading related practices

[Peter Cousins <pe...@itemfield.com>]

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?

 

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.

 

* 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.

 

 

Re: Questions regarding threading related practices

[Jim Marino <jm...@myromatours.com>]

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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org