cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Identification of Partial Responses
Date Thu, 11 Jan 2007 17:44:12 GMT
A quick question about the two way case - if its already decoupled, why
can't the server sent out a <SequenceAcknowledgement> at some point during
the two way operation. For instance we have this scenario

- A sends message to B
- B takes an hour before it sends its response back to A
- During this time B sends a one way SequenceAcknowledgement to A so as to
avoid resends

Thanks,
- Dan


On 1/11/07, Dan Diephouse <dan@envoisolutions.com> wrote:
>
>
>
> On 1/11/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> > > 1. Remove isPartialResposne from HTTPConduit - this logic
> > > isn't right as it depends on a certain HTTP response code. I
> > > think the best way to test to see if we have a response
> > > message is to just check and see if the contentType is null.
> > > If it isn't, there is a message. If it is null, then there is
> > > no message.
> >
> > Well, null content-type or zero content-length, not sure which is most
> > general and reliable indicator.
> >
> > Currently the logic is reponseCode == 202 && contentLenght != 0, so we
> > could simplify this to contentLenght != 0, or check for null-ness of the
> > content-type instead as you suggest.
>
>
> Content-Length will often times not be set though as many people need to
> do a chunked responses.
>
> > 2. RM logic shouldn't need anything special now, just
> > > recognition of a <SequenceAcknowledgement> in response to a
> > > one way message.
> >
> > Remember the SequenceAcknowledgement could also be in a partial response
> > to a twoway request (case B as described in an earlier mail on this
> > thread).
> >
> > 3. Remove isPartialResposne from ClientImpl. This call is
> > > really superflous as we are going to return as soon as the
> > > one way message is sent anyway - we aren't blocking for a
> > > response since we check for isOneWay on line 160.  We should
> > > also change our logic so that we only look for response
> > > objects if the call is one way.
> >
> > Are you assuming that partial responses are only sent for oneways?
> >
> > If that were the case, then the full/partial response recognition issue
> > would indeed go away.
> >
> > But alas, case B requires that twoway requests may also attract partial
> > responses. In this case, we would indeed be waiting for a full response
> > in ClientImpl, so we need to be able to make the distinction between
> > full and partial responses in ClientImpl, so I can't see how the
> > ClientImpl.isPartialResponse() logic is superfluous.
> >
> > Recall the issue that got this whole discussion started ...
> > distinguishing a partial and full response to a bare doc/lit *twoway*
> > operation with void return type. The <SOAP:Body/> is empty in both
> > responses, hence the need to distinguish in some other way.
>
>
>
> Ah shit, forgot about the two way case.
>
> *heads back to drawing board*
>
> --
> 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