Comments inline.
Simon
Raymond Feng wrote:
Comments inline.
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, August 20, 2007 5:14 PM
Subject: Re: Do we still need special handling of callback bindings and
wires?
The short answer is Yes. The long answer follows below :-)
I'll describe the design approach used by the code in my patch for
TUSCANY-1496. Things are moving rapidly in this area with Raymond's
work to support late binding between references and services, so some
of this description may need to be updated.
It's my turn to update the discription now :-)
Wires may be reference wires or service wires:
1. Reference wires connect a source reference to a target binding
and endpoint. The source reference could be a callback service's
pseudo-reference.
2. Service wires connect a binding endpoint to a service implementation.
The service implementation could be a callback reference's
pseudo-service.
Reference wires may be static or dynamic:
1. A static wire targets a specific binding and endpoint (local or
remote). Dispatching a call down an invocation chain for this
wire results in a call to the statically configured binding and
endpoint for the wire.
2. A dynamic wire targets a specific binding but an unspecified
endpoint. The actual target endpoint is provided at invocation
time. Depending on the binding type, dynamic wires may perform
worse than static wires, or their performance may be the same.
Some bindings may only support static wires. Some may only support
dynamic wires. Some may support both, with static wires providing
better performance.
I'm not sure why you think it's the binding's job to support static or
dynanic wire. To me, the dynamic wire needs to be bound an endpoint
before it can used for invocations.
Maybe the terminology "static" and "dynamic" is confusing here. By
"static" I mean a wire that is bound to a specific target endpoint and
all invocations down that wire will go to this pre-bound endpoint.
By "dynamic" I mean a wire that is not pre-bound to a specific endpoint,
allowing each invocation down the wire to specify its target endpoint.
Some bindings can optimize if they have have static knowledge of the
target. The local SCA binding is in this category, because static
pre-knowledge allows the source and target invocation chains to be
connected (now by means of the binding invoker), so that each invocation
becomes a direct call through pre-built invocation chains.
Other bindings perform the same whether or not they have this static
knowledge. The Axis2 Web Service binding is in this category, because
it always creates an Axis2 operation client for each request, and it
passes the target endpoint into Axis2 as a creation parameter for the
operation client.
Requiring all wires to be be pre-bound to a target endpoint before they
can be used for an invocation would require many more wires to be created
than is necessary. An extreme case of this is callbacks over Web Services
from multiple clients to a single service, where the service's callback
pseudo-reference should not use a separate callback wire for each client
but should have a single dynamic wire that can invoke any client endpoint.
Forcing every callback operation to create and bind a runtime wire first
is unneccessary and will incur both time and space costs.
Service wires are effectively always static since on the service
side, the binding and endpoint is known. Every service and binding
combination has a single service wire that is used by the binding
provider to invoke the service.
For statically connected references and services (e.g., wired in SCDL,
using an SCA binding, and locally accessible), static forward wires
are created. The core can't fully complete the end-to-end invocation
chain for the static wire, so the start methods of bindings that
support local optimization (like the local SCA binding) can complete
these connections using information provided by the core.
Now we support the lazy creation of RuntimeWire/Invocation for a
reference. I also changed the code to have the RuntimeSCABindingInvoker
to delegate the call to the first invoker in the target service chain
instead of trying to merge/connect the two chains together.
Lazy creation is fine, as long as it does not compromise performance.
I looked at some of the code that does this and I am concerned about
the impact on performance (see below for more specifics). Having
RuntimeSCABindingInvoker delegate to the service's invocation chain
instead of linking the invocation chains seems a better approach.
If the statically wired reference/service pair defines a callback
interface, static wires for callback purposes are created from the
pseudo-reference to the pseudo-service (this is what the code at
line 503 is doing). Again, the binding's start method may perform
invocation chain optimization. These static wires for use by callbacks
provide an optimized callback path for cases where the target of the
callback can be predicted in advance based on wiring information.
For references where a static target is not always known at wiring time,
a dynamic wire is created by the core. All callback pseudo-references
fall into this category, as do forward references that have wiredByImpl
semantics. Even callbacks that are statically wired will have a single
dynamic wire in addition to their static wires. The dynamic wire is
needed because there is always the chance of the callback service being
called through a service reference that has used a callback object
service reference to redirect the callback to a destination that could
not be predicted at static wiring time. The static wires are an
optimization that is likely to produce better performance when the
callback destination corresponds to a static wire.
When a callback is made at runtime, the invocation handler attempts to
locate a static wire whose destination endpoint matches the callback
destination endpoint. If one is found, this wire is used to provide
best performance. If one is not found, a dynamic wire can be used if
supported by the binding, or a new static wire can be constructed at
runtime. Think of the collection of static wires as a cache to optimize
calls to known destinations, with this cache either being partially
pre-populated by the code at line 503 or built dynamically on demand as
callbacks are made.
On the service side, I don't think we should create static wires for
references corresponding to the service callbacks at all. I updated some
of the code to bind the dynamic wire to the callback endpoint in the
context of an invocation. Then the dynamic wire (cloned) becomes a
static wire after the target endpoint is bound.
I don't understand why we would be creating static wires for forward
calls through a direct wire but not be doing this for the callback path.
If the interface is a callback interface, then I would expect the
performance of callbacks across a wire to be comparable to the performance
of forward calls across the same wire. By creating the callback wires at
the same time as the forward wires, we ensure that this is the case.
This would be less of a concern if the new code for deferred creation
achieved performance similar to these static wires, but it doesn't.
From looking at the code, it appears that on every callback call, a
cloned runtime wire (with a set of invocation chains) and a cloned
runtime component reference are created. This seems very expensive and
it is not necessary for callbacks over the Web Service binding (because
of the inherently dynamic nature of this binding) or for statically wired
callbacks over the local SCA binding (because the overhead of creating
the cloned wire and reference far exceeds the cost of making the
callback call).
I tried to run a test to measure the performance impact of this change
and I got an unpleasant surprise. I modified the simple-callback sample
to loop through a large number of callbacks from a single forward call.
The current code failed after 6000 callbacks and the previous code
failed (in a different way) after 90000 callbacks. I haven't been able
to dig into this enough yet to figure out why the number of callbacks
is limited in this way.
It isn't essential to pre-create static wires for either forward calls
or callback calls. Deferring this creation is fine, as long as it is
done in an optimal way that makes the most of static wiring knowledge
where that exists and is useful. Also, we should ensure that once
these static wires are created, they are cached in an appropriate way
so they can be reused.
Simon, did you create the static wires from service to reference for
performance optimization? I assume the dynamic association is not heavy
at all.
See above. Yes, creating these static wires is a performance optimization.
I don't see any reason why we should make callbacks perform worse than the
corresponding forward calls across the same wires. Similar good performance
could potentially be achieved with deferred creation of these wires (for
both forward calls and callbacks) if we have a caching strategy to ensure
that static wires are always reused when possible.
The code at line 579 has a different purpose. This is setting the
callback endpoint (pseudo-service) to pass with a forward call, so
that the target service knows where to direct any callbacks that
may occur.
Simon
Jean-Sebastien Delfino wrote:
Now that callbacks are represented as regular services/references,
are the "if (callback.....) { .... }" on lines 503 and 579 of
CompositeActivatorImpl still necessary?
If yes, then the next question is: Why? :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
