cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Client API, EPRs
Date Tue, 13 Mar 2007 16:15:17 GMT
On 3/13/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
> *snip*
>
> Sure JMS is different, but that doesn't make it an edge-case that we can
> disregard.


We still need to support it at some level of course. And in the future we
can support it at the EPR level too. What is so bad about that?


> And as I stated, that would seem to defeat the purpose.


For this single case. And in the future this single case probably won't be
valid. So your objection here really doesn't carry much weight.

> > Third, when the
> > > > decoupled destination is being set up it can still pull
> > > > configuration from xml files if people need to add extra
> > > > configuration info.
> > >
> > >
> > > Wouldn't that defeat your stated purpose? (i.e. not having to do
> > > transport-specific config)
> >
> >
> > Yes, I was simply stating this is a possibility if the user
> > needed to fall back to it. Hopefully they wouldn't need to.
>
>
> Seems a lot simpler to me to drive this from config, which we know works
> for every transport.
>
> Actually, let me restate that ...
>
> It would seem simpler to drive this via policies, that may be taken from
> static config files, or equivalently may be dynamically set by the
> application. I believe Andrea is using the latter approach to control
> the decoupled endpoint(s) used in system test she's writing.
>
> Maybe that would be a compromise that give the best of both worlds?
>
> I would like to maintain some cardinality restriction on the
> (automatically launched) decoupled response endpoint, by keeping it
> per-Conduit as opposed to per-request (for reasons of lifecycle mgmt and
> non-proliferation as I explained earlier on this thread).
>
> But apart from that, I've no problem with the URI (or whatever the
> transport needs) originating from the application code as opposed to the
> cxf.xml.


Can you be more specific about what you mean by policy driven? I looked
through the RM code a bit, but I'm still not sure what you're referring to.

I'm fine with limiting automatic launching to be per-Client.

And just to be incredibly clear, I'm specifically trying to get away from
the xml approach and make complete control of the endpoints easy when using
the Client API.

>
> > I think you're oversimplifying the issue. Either you're trying to:
> > a) count the number of clients which are actively invoking.
> > In which case when I stop sending and then resume a minute
> > later you're going to have to start it all over again, which
> > wouldn't make a lot of sense. Especially in a single thread
> > scenario as it would be starting & stopping a server during
> > each invocation.
> >
> > b) Implement a timeout mechanism. In which case it would work
> > equally well when setting a reply-to EPR on a Client.
> >
> > c) Implement a refcount & timeout mechanism. i.e. if I call
> > close on my conduit, but another client still has the same
> > decoupled server/port open we would obviously want it to stay
> > up. Which once again works equally well when setting a reply
> > to EPR on the client.
> >
> > d) Trying to call Conduit.close() when the client is being
> > GC'd. But there is no sure way to do this Java. Even if you
> > could, this would once again work equally as well when
> > setting an EPR on the Client.
>
>
> There's no question of what's there being an attempt to be timeout-based
> or reliant on GC.
>
> Instead the idea in the original Celtix code was to use a reference
> counting scheme for the decoupled response endpoint, and to allow this
> to be shared across client transport instances. This was simply not
> ported over properly to CXF.
>
> The original scheme worked as the HTTPClientTransport was created once
> per binding instance, had well-defined shutdown semantics, and reused if
> possible a pre-existing listener for the decoupled endpoint, even if
> this was created from another HTTPClientTransport. This reuse was easy
> to do as HTTPClientTransport registered the Jetty handler directly,
> instead of going thru' the DestinationFactory, and thus could easily
> check if a pre-existing handler was already registered.


I don't see how this gets around the issues I mentioned in (a). It sounds
like the deocupled destination would stick around until you shut down the
HTTPClientTransport. And there is no way to automagically shut down the
client transport really.


> > Lets say I define a
> > > > replyTo endpoint in my cxf.xmlfile. Its not going to get
> > shut down
> > > > until I specifically shut it down myself or until I shut the
> > > > appserver down. So letting CXF create a destination automatically
> > > > would not really be any different. It just makes it
> > easier for the
> > > > user to set up the decoupled endpoint via the API. Once they are
> > > > done with the client they could call
> > > > Client.getDestination().shutdown()
> > > > and release any resources.
> > >
> > >
> > > I'm not sure it would be that simple.
> > >
> > > The user may have specified different decoupled destinations for a
> > > series of invocations mediated by the same Client instance.
> >
> >
> > So are we going let these accumulate and then have a
> > > close-all-in-one-fell-swoop type API on Client, say
> > > shutdownAllDestinations()?
> >
> >
> > This is an issue *regardless of how you are setting up the decoupled
> > destination.*  The only way to auto-close them is to combine
> > it with a refcount/timeout mechanism like I outlined above or
> > to have the user explicitly close them (either on a per
> > request or client lifecycle basis).
> >
> > But that would have the effect of the client hogging
> > transport resources
> > > (e.g. HTTP ports or JMS Destinations) for much longer than
> > necessary,
> > > i.e. for the period after the client has stopped using these as the
> > > replyTo for requests, but before the corresponding JAX-WS proxy or
> > > whatever goes away.
> > >
> > > Also there's the issue of what WS-RM uses as its acksTo
> > address. AFAIK
> > > this is still just the decoupled endpoint associated with
> > the Conduit.
> > > However, it needs to continue to be available to receive
> > ACKs for the
> > > lifetime of the RM sequence. So we don't want the application to be
> > > able pull the rug out from under RM by specifying a
> > short-lived replyTo.
> >
> >
> > There are a couple ways to solve this:
> > - We can ref count the decoupled server endpoint. If the
> > client closed, there would still be an outstanding reference
> > to the server. So the server endpoint wouldn't close until RM
> > terminated its sequence and it called
> > close() on the decoupled destination.
> > - We could add extension points via a Client.close() API so
> > that RM could terminate the sequence and shut down the
> > decoupled destination when its called.
> >
> > This brings up an interesting point: Currently I can only
> > associate a decoupled destination with a client's conduit
> > AFAIK. But this makes absolutely no sense to me - there are
> > many decoupled destinations that could be associated with a
> > client. For instance it might have a different acksTo then
> > ReplyTo. Or I might have a different FaultTo.
>
>
> I don't think you're correct here. If I go and explicitly set the
> replyTo to a Destination that I've created (via a DestinationFactory)
> then this will be used for the <wsa:ReplyTo> in the outgoing message, as
> opposed to the back-channel destination overwriting the explicit
> setting.
>
> Similarly the acksTo could be set to any Destination, but RM just
> happens to be implemented to use the back-channel destination for
> convenience. By convenience, I mean it avoids the RM layer having to set
> up a separate in-interceptor-chain to handle incoming out-of-band
> messages.
>
> The per-Conduit restriction only applies to *automatically launched*
> decoupled response endpoints. The application can go nuts explicitly
> creating response endpoints all over town if it wants ...
>

First, I was talking about from a configuration point of view.

Second, doesn't this kind of defeat the point of having the decoupled
destination in the conduit?

- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

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