Re: Do we still need special handling of callback bindings and wires?

[Greg Dritschler <gr...@gmail.com>]

I missed it when it happened, but it appears that this discussion was
settled (not sure where or how) in favor of not ever creating static wires
for callbacks.  Why is that?  I have no idea what the performance cost is
one way or the other, but I agree with Simon Nash that it seems a bit
strange to have static wires in the forward direction and only a dynamic
wire in the callback direction.

Greg Dritschler

On Aug 21, 2007 11:00 AM, Simon Nash <na...@hursley.ibm.com> wrote:

> Comments inline.
>
>   Simon
>
> Raymond Feng wrote:
>
> > Comments inline.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message ----- From: "Simon Nash" <na...@hursley.ibm.com>
> > To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>