Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950701110944u5db75d1foddeb815d2fdd61f5@mail.gmail.com>
Date: Thu, 11 Jan 2007 12:44:12 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Identification of Partial Responses
In-Reply-To: <7b774c950701110930m792c8e8q14b0e83481985a3e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_24351_32879674.1168537452663"
References: <FA1787F64A095C4090E76EBAF8B183E071FB75@owa-emea.iona.com>
	 <7b774c950701110930m792c8e8q14b0e83481985a3e@mail.gmail.com>

------=_Part_24351_32879674.1168537452663
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_24351_32879674.1168537452663--