cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: [PROPOSAL] Client and Conduit changes
Date Fri, 30 Mar 2007 14:33:02 GMT
On 3/30/07, Glynn, Eoghan <> wrote:
> > -----Original Message-----
> > From: Dan Diephouse []
> > Sent: 30 March 2007 01:52
> > To:
> > Subject: Re: [PROPOSAL] Client and Conduit changes
> >
> > On 3/29/07, Glynn, Eoghan <> wrote:
> > >
> > >
> > >
> > > > But where are you diverting it?
> > >
> > >
> > > The diversion would be driven by an interceptor, to a target within
> > > the local process space.
> > >
> > >
> > > > How do you want to divert?
> > >
> > >
> > > By dynamically manipulating the trailing interceptor chain.
> > >
> > >
> > > > Why?
> > >
> > >
> > > To avoid unnecessary dispatch overhead where the target
> > exists within
> > > the client process space.
> >
> >
> > Unnecessary dispatch overhead? By calling and
> > close()? Are you just trying to avoid serialization?
> Direct quote from my last mail ...
> 'The "its not really needed" case would occur when we detect during the
> dispatch that marshalling and transport involvement are not required.'

So clearly I'm not *just* talking about calls to and
> close() ...
> On an aside, an open() method doesn't exist in the Conduit API, but I
> assume you mean here the ConduitInitiator.getConduit() call.

Yes, my bad.

What I'm talking about is avoiding *any and all* overhead that would be
> unnecessary if the message is not leaving the current process space.
> That overhead includes the getting the Conduit,

Overhead in getting the Conduit happens only once at Client creation.  And
in the case of a local invocation it really results in just a call to new
LocalConduit(), which I'm sure is not a bottleneck.

marshalling the message

A Conduit doesn't imply marshalling. For instance, I've outlined how we
could use an ObjectBinding (which we'd want to write for either case) with
the local transport. Currently the local transport requires you write to the
output stream, but this doesn't have to be so. I at least fixed the input
side so we can directly invoke a service, but more changes are needed.

payload & headers,

These are interceptors, and would be configured as part of the binding. And
hence in the local dispatch scenario they would not be part of the Binding,
and therefore would not be part of the interceptor chain.

and possibly applying transformations such as
> encryption or compression.

These are up to the user to enable on their endpoint. I don't see why these
would be enabled if you're invoking a local endpoint.

This "overhead" that you're talking about seems completely unrelated to the

> *snip*
> > >
> > > And conversely, setting up the Conduit in the
> > Client.invoke() is IMO
> > > *too early* in general. We're only 100% sure we need a
> > Conduit when we
> > > get to a point in outbound interceptor chain that actually needs to
> > > use a Conduit for something. This point is the
> > > MessageSenderInterceptor. So my proposal is to defer getting the
> > > Conduit unless and until this point is reached.
> >
> >
> > In general?
> Yes, in general.
> In the sense that in many cases its OK to get the Conduit in
> Client.invoke(), but in other cases it doesn't make sense to do so.
> So in general its not the right thing to do.

I don't see how that follows... In general it IS the right thing to do and
in some use cases that you outline it may not be the right thing to do. But
I'm not convinced yet that we can't just create a conduit in general and
then not use it.

> > If we don't ultimately use this Conduit, this shouldn't be
> > any issue. Any resource intensive operations should be
> > delayed until open() is called.
> As it happens, that is the case with all our extant Conduit
> implementations.

Now would be a good time to fix that.

However, it may not be the case for all future Conduit implementations,
> and its certainly not part of the Conduit contract as-is.
> I could for example envisage a defensively-coded Conduit probing the
> target upfront in its ctor so as to fail-fast if a connection would be
> impossible to establish.

This would be bad. What if the target doesn't exist yet because the server
isn't fully intialized. We shouldn't be checking for existance until send()
is actually called.

I can also envisage resources to be shared across Conduit instances
> being set up in the initial ConduitInitiator.getConduit() call, as
> opposed to being deferred to the first Conduit.send().
> Of course we could spell out a requirement that a Conduit implementation
> doesn't do any heavy-lifting until the first send() occurs. But I could
> see potential transport authors thinking, why doesn't the CXF runtime
> just avoid making the ConduitInitiator.getConduit() call if its not sure
> it needs the Conduit?

Because we want to make ClientImpl.getConduit() available to people. Seems
like a simple enough reason to me.

Your arguments are often based on making life easier for potential
> transport-writers.

And transport users!

And here's a case where we can avoid imposing an
> ambiguous post-condition on ConduitInitiator.getConduit(). By
> "ambiguous", I meaning adding javadoc like "don't do anything resource
> intensive until Conduit.send() is called". Whether the transport author
> respects this is not verifiable (we're not coding in Eiffel), also it
> could be open to mis-interpretation (e.g. would 'resource intensive'
> include pulling in config values?).

They can do some set up when the conduit is created. I don't think
transports will necessarily have that much over head providing they aren't
initializing connections. Since this only happens once when the Client is
created it shouldn't be a big deal.

> >
> > My point is that a user should just be able to do
> > client.getConduit() and change some transport settings. They
> > shouldn't have to explicitly create the Conduit though, which
> > is what your proposal does.
> >
> > What about just a ClientImpl.setInitializeConduit(false)?
> That would be fine if the default for initializeConduit was false (as I
> don't think the application should have to make an explicit API call to
> get the correct, IMO, behavior).
> Also I guess you'd probably want to extend your <client> config bean
> with an <initializeConduit> property (and similarly, I'd advocate false
> as the default value).

I'm sorry, but I can't ever be +1 on this.  We need to have the Conduit
created on the Client for the user by default.

> >
> > Yeah, but they're still going to look at the Conduit
> > interface and wonder about what that method is. And on the
> > other side of things, as a user of the Conduit interface you
> > still need to understand Conduit.getBackChannel(). And then
> > if we don't go down the route of removing decoupled
> > destinations from the Conduit, they'll also have to
> > understand the ConduitPolicy interface.
> >
> > Do you see my point now?
> I suppose it just doesn't seem like that big an issue to me, especially
> if we make it clear in the javadoc that getBackChannel() only needs to
> be overridden in very specific circumstances.
> Similarly, the transport-writer doesn't really have to worry about the
> mechanics of the ConduitPolicy. Beyond knowing that it factors out some
> commonality, and they should extend in their config schema *if* they
> need transport-specific conduit config.

You're the one who wrote it though, so of course it makes sense :-). There
have been several other people though have noted that it is overly complex,
and I think we need to listen to them.

- Dan

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message