cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Understanding Partial Responses [Re: Identification of Partial Responses]
Date Wed, 10 Jan 2007 15:52:45 GMT

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
> 

Mime
View raw message