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]
