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 <[EMAIL PROTECTED]> wrote:
On 1/11/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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
