I finished the changes this evening... Ignacio, you should be good to
go with your changes.
Jim
On Sep 28, 2006, at 5:07 PM, Jim Marino wrote:
Ignacio, Greg, Dave, Jeremy, and myself had a discussion today
about how thread dispatching for non blocking calls should work. We
identified two basic use cases:
1. Component-to-Component (c2c)
2. Component-to-Reference (c2r)
In each case there is a per-operation interceptor chain associated
with the source and target, outbound and inbound chains
respectively. In the current architecture, for c2c non-blocking
invocations, a thread is spawned in the target invoker after the
message is flowed through both interceptor stacks. This means that
both the inbound and outbound chains are called on the thread where
the invocation originated. For c2r non-blocking invocations, it is
up to the binding to perform whatever dispatch is required, so no
thread is spawned by the reference target invoker.
Greg and Dave have brought up some good use cases and we came up
with what we think is a better approach. For c2c non-blocking
invocations, the target invoker will no longer be responsible for
spawning threads. Instead, a bridging interceptor will be placed
between the outbound and inbound chains that will perform the
thread switch. Interceptors in the outbound chain will run on the
same thread as the original invocation. Outbound interceptors may
be responsible for placing context in a message (e.g. security,
transaction ids). The non-blocking bridging interceptor will spawn
a thread and continue the invocation on the target inbound chain.
For c2r non-blocking invocations, a thread will not be spawned as
it is up to the binding to decide what needs to be done (it may
rely on the binding api to do this if it is non-blocking). This
means that both interceptor chains will be run on the same thread.
It will be up to the connector to make the determination of which
type of bridging (blocking or non-blocking) to interpose as the
outbound and inbound wires are fused. We are going to make these
changes incrementally. I'm going to change the wiring
infrastructure to support this, which shouldn't impact other
subsystems or extensions except for async target invokers (they
will just need to dispatch synchronously unless they are a special-
case binding). We are then going to look at whether we need an
async target invoker at all, but do this once we complete the first
work item.
Jim
---------------------------------------------------------------------
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]
