cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Understanding Partial Responses [Re: Identification of Partial Responses]
Date Wed, 10 Jan 2007 16:13:03 GMT
OK, thanks Eoghan, I missed that before.

My point in bringing this up is that if its a proprietary feature in CXF, we
could just add an Action header if we wanted to make it clear what the
message is.

As far as I know, other implementations get around this by having a polling
feature. This has now been formalized as the MakeConnection operation in the
WS-RX spec. In essence it involves making a connection to the server from
the client for the exclusive purpose of sending back the acknowledgments.
Microsoft implemented something similar to this for earlier versions of the
spec, but it was never formalized.

Also, if this is a proprietary feature for earlier versions of the spec, and
if the world is moving toward the MakeConnection type of operations, why
don't we just implement a similar thing for the old version of the spec?
Performance wouldn't be bad and it would be a lot easier to implement.

- Dan

On 1/10/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
> Dan,
>
> Partial responses have *nothing* to do with performance.
>
> Rather they are a way of acknowledging incoming messages in scenarios
> where ACKs either:
>
> 1. cannot be sent in any other way, or
>
> 2. are unlikely to be sent in a timely fashion (so as to avoid spurious
> resends)
>
> To quote from a mail I sent earlier on a related thread:
>
> <quote>
> "lets consider the fundamental question as to why we originally came to
> the conclusion that partial responses are needed by RM.
>
> Its basically to allow timely ACKs to be sent in two specific scenarios.
> Where the client's source sequence has an anonymous acksTo (so that ACKs
> must be piggy-backed on responses rather than being sent standalone),
> and either:
>
> A) the client invokes a series of exclusively oneway operations, so that
> there are no application-level responses ever sent back), hence no
> opportunity to piggy-back ACKs
>
> or:
>
> B) the client invokes a series of non-interleaved twoway operations, but
> the implementor up-calls are sufficiently long-lived so that a response
> will only become available *after* the client's retransmission interval
> has expired, so that the client has already resent the message before
> the server gets a chance to acknowledge the first message instance.
>
> Note that partial responses are only required when the acksTo is
> anonymous"
> </quote>
>
> In the case of your example of an "application consisted solely of one
> way messages" (i.e. my case A above), partial responses are sent if (and
> *only* if) the acksTo address is anonymous. This means the destination
> cannot "only acknowledge every so often", in the sense of sending ACKs
> out-of-band from the stream of incoming oneway requests. The ackTos is
> anonymous, so the *only* conduit on which a ACK can be sent is the
> back-channel of the incoming client->server connection. But since the
> incoming requests are all oneway, and thus never attract a full
> response, the ACKs *must* be sent as a partial response.
>
> I can't explain it any clearer, short of repeating myself endlessly.
>
> The reason your google search for "partial response" showed up nothing
> is that we invented the phrase. I don't know precisely what other RM
> implementations do to account for cases A) and B) above, but I would
> guess that they either do not fully support anonymous acksTo or do
> something similar to what we do. We should do some more interop testing
> to find out definitively.
>
> /Eoghan
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 10 January 2007 15:16
> > To: cxf-dev@incubator.apache.org
> > Subject: Understanding Partial Responses [Re: Identification
> > of Partial Responses]
> >
> > Been trying to educate myself some more on this issue, and
> > I'm remaining stumped. I don't see any mentions of such a
> > feature in the 2005/02 spec or even in the latest WS-RX
> > draft. Searching the web didn't reveal anything really
> > besides CXF/Celtix artifacts.
> >
> > So I have another question in addition to my one below - what
> > is the benefit of partial responses? I remember someone
> > citing performance benefits to me.
> > However this seems rather unlikely as SequenceAcknowledgment
> > piggybacking will be possible in most scenarios.
> >
> > Even if your application consisted solely of one way
> > messages, the only way to do RM with decent performance is to
> > only acknowledge every so often. An HTTP connection back to
> > the message sender is unlikely to be the performance
> > bottleneck. Especially when you factor in the sizes of the messages.
> > Acknowledgments are about as small as a message gets, and I
> > would guess that typically the application messages will be
> > larger. Since XML parsing is where the bottleneck is (HTTP
> > introduces some latency which isn't an issue for seqacks and
> > represents maybe 20% of the raw time), doing a partial
> > response seems unlikely to have any net benefit.
> >
> > What am I missing here?
> >
> > - Dan
> >
> > On 1/9/07, Dan Diephouse < dan@envoisolutions.com> wrote:
> > >
> > > So there aren't any distinguishing characteristics of a
> > partial response?
> > > Are partial responses documented anywhere?
> > >
> > > Also, what other vendors are doing partial response?
> > >
> > > On 1/9/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
> > > >
> > > > Dan Diephouse wrote:
> > > >
> > > > > Quick question regarding #2 - Do other RM
> > implementations include
> > > > > a RelatesTo header in partial responses?
> > > > >
> > > > > Also, could we determine if its a partial response by
> > checking to
> > > > > see if the Action is a SequenceAcknowledgement?
> > > >
> > > > No, partial responses do not have the action set.
> > > > A message with action SequenceAcknowledgement indicates that the
> > > > underlying message is a oneway, and was issued by an RMSource
> > > > out-of-band (e.g. when a timer signals as opposed to when
> > the client
> > > > makes an invocation/the server sends a response). It also has an
> > > > empty body (info is carried in the
> > SequenceAcknowledgement header).
> > > > When SequenceAcknowledgemens are piggybacked on an application
> > > > message (
> > > >
> > > > in case of anonymous AcksTo on  partial responses, in case of
> > > > acksTo== replyTo on full responses), the action is that of the
> > > > underlying application message (null in case of partial
> > responses).
> > > >
> > > > Andrea.
> > > >
> > > > >
> > > > > - Dan
> > > > >
> > > > > On 1/9/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> OK, back to the drawing board on this one :(
> > > > >>
> > > > >> A quick google on this question suggests that, notwithstanding
> > > > >> some confusion, an empty SOAP body is actually kosher
> > in certain
> > > > >> circumstances ... see for example [1].
> > > > >>
> > > > >> So off the top of my head, I think we'd have to do
> > something like
> > > > >> the following to make the partial/full response
> > distinction more
> > > > >> bullet-proof:
> > > > >>
> > > > >> 1. Stop sending the wsa:RelatesTo in the partial
> > response (this
> > > > >> is potentially misleading in any case) 2. Set something like
a
> > > > >> Message.IS_RESPONSE property to false in the WS-A layer if the
> > > > >> wsa:RelatesTo header is not present 3. Replace the
> > > > >> ClientImpl.isPartialResponse() logic with
> > > > >> Boolean.FALSE.equals(inMessage.get(Message.IS_RESPONSE))
> > > > >>
> > > > >> Checking via Boolean.FALSE.equals() would ensure that the
> > > > >> ClientImpl logic would be valid even if WS-A layer was
> > absent (in
> > > > >> which case the
> > > >
> > > > >> IS_RESPONSE property would be null, but we can assume that a
> > > > >> partial response would never be received, as this may
> > only occur
> > > > >> if WS-A
> > > > headers
> > > > >> were present in the corresponding request).
> > > > >>
> > > > >> Cheers,
> > > > >> Eoghan
> > > > >>
> > > > >> [1]
> > > > >>
> > http://lists.jboss.org/pipermail/jbossws-issues/2006-October/0000
> > > > >> 22.html
> > > >
> > > > >>
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: Andrea Smyth [mailto: andrea.smyth@iona.com]
> > > > >> > Sent: 09 January 2007 09:58
> > > > >> > To: cxf-dev@incubator.apache.org
> > > > >> > Subject: Identification of Partial Responses
> > > > >> >
> > > > >> > Further to the dicussions on the
> > > > >> > "JaxwsInterceptorRemoverInterceptor and RM" subject on the
> > > > >> > different ways to identify a partial response I came
> > accross an
> > > > >> > example of application messages with empty soap bodies.
> > > > >> > This is in the
> > > > >> > org.apache.cxf.systest.basicDOCBare.DOCBareClientServerTest
> > > > >> > system test, where the response to the putLastTradedPrice
> > > > >> > invocation is a soap message with an empty body.
> > > > >> > Addressing is not involved.
> > > > >> > First off, is the empty ssoap body OK and to be expected?
> > > > >> > Secondly, if it is, what should I expect if this
> > client-server
> > > > >> > setup uses addressing and non-anonymous ReplyTo? It seems
we
> > > > >> > can distinguish the partial response from the real
> > response not
> > > > >> > by checking for an empty body (regardless if this results
in
> > > > >> > empty of no list content in the
> > > > >> > message) but need to look also at the addressing headers
...
> > > > >> > Any ideas?
> > > > >> >
> > > > >> > Andrea.
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>



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

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