OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] i130 - what does ack interval refer to


Taking it down a level, we have two proposed wordings:

   1. This element, if present, specifies the maximum duration, after
      receipt of a reliably sent message, which the RM Destination will
      wait before transmitting an acknowledgement.  If omitted, there is
      no implied value.
   2. This element, if present, specifies the maximum duration between
      acknowledgements for this Sequence.  The RM Destination will
      transmit an acknowledgement at intervals at most this far apart. 
      If omitted, there is no implied value.

Another question for the group: In either case, are we introducing the 
word "transmit" in a way which prevents use with Make Connection?  This 
isn't quite like "generating" a fault (versus sending it) but might need 
similar handling in the specification.

I favour option 2 above because it supports a use case Doug is concerned 
about (the RMS deciding to retry based on not receiving an expected 
acknowledgement), provides more information than option 1 for that 
scenario, and also provides that heartbeat Doug mentioned below.  Not 
sure a heartbeat is always or often required (might be a SLA concern) 
but it comes somewhat for free in this case.

Of course in option 2, a particular sent acknowledgement could duplicate 
earlier acknowledgements, and the RMS may actually not have tried to 
deliver anything in that interval.  This "waste" seems minor when 
compared with the RMS making decisions based on provided information 
instead of the absence of information.  The absent information is the 
acknowledgement clearly listing all of what the RMD received.  The RMD 
and RMS may have different perspectives on "dead air" (outbound messages 
may have been lost).  Option helps to distinguish lost messages from 
other conditions.

thanx,
    doug

PS. Doug and I argued me out of any suggestions related to minimum 
intervals.  The main use case for such a value would be dynamically 
scaling the RMS Acks To end point in preparation for an expected flood 
of acknowledgements or some similar message flood planning.  If such a 
dynamic enterprise were in place, the scaling could happen as incoming 
messages *actually* increase in number but still well in advance of 
overloading the RMS.

On 21/06/06 18:32, Doug Davis wrote:
>
> All,
>   Doug Bunting and I have been discussing issue 130 ("what does ack 
> interval refer to")
> and we've hit a bit of a roadblock.  There are two (perhaps more) ways 
> of interpretting
> what the AckInterval (AI) value is meant to be used for, or what its 
> intended meaning is supposed
> to be.  The two, most likely, options are:
> 1 - the maximum time the RMD will wait, after receipt of a message, 
> before an Ack will be sent
> 2 - the maximum time the RMD will wait before between sending Acks
>
> Option 1 means that the RMD will wait no longer than the AI value 
> before it sends an Ack. The
> RMS can be assured that if it doesn't get an Ack from the RMD after 
> that time then the Ack
> was lost.  Note: a new msg into the RMD initiates the timer and the 
> sending of an Ack stops it.
>
> Option 2 means that the RMD will send out an acknowledgement, at 
> least, every AI milliseconds.
> Sort of like a heartbeat.  The RMS can be assured that it will not 
> need to wait any longer than the
> AI before an Ack will be resent.  Note: the sending of an Ack will 
> reset the timer and it will only stop
> upon termination of the sequence.
>
> Note: in both options the RMD is always free to send more acks and the 
> RMS is always free to
> send an AckReq - but we're not worried about those situations.
>
> The current wording is a bit ambiguous.So, the question for the TC 
> is....which option do we
> want to present in the spec?  Thoughts?
>
> thanks,
> -DougD 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]