On 17 October 2016 at 16:57, Alan Conway <acon...@redhat.com> wrote:
> On Fri, 2016-09-30 at 14:40 +0100, Rob Godfrey wrote:
>> I don't think it's a bug - it's a completely valid (if chatty)
>> To my mind the semantics of the field are this:
>> The sender of the open frame is saying "if I do not receive any data
>> for this period of time, I reserve the right to assume that you are
>> longer functioning correctly"
>> On receiving this information, the peer should decide on a strategy
>> that ensures to the best of its ability, that if it is functioning
>> normally it will be generating data sufficiently frequently that the
>> condition does not occur. If this peer knows that it is susceptible
>> to delays outside its direct control (such as garbage collection
>> pauses) it should take account of this in how often it schedules
>> sending heartbeat frames.
>> At the same time, the sender of this value should give some leeway
>> before actually shutting down to account for unexpected transport
>> delays, or processing delays on its side. Since it is unaware of the
>> nature of the allowances made at the peer, it may decide to be
>> particularly generous in the leeway it grants.
>> I think the spec mentioning a ratio (such as twice) is massively
>> In terms of the API - what is the applications intent in setting the
>> value? Is the intent to ensure transport activity within a specific
>> period, or to set a hard limit on how long the library will wait
>> before generating some sort of timeout exception?
> My guess is that in terms of the API, the application's intent in
> calling "set_idle_timeout(T)" is to set the formally-specified AMQP
> value called "idle-timeout" to T. I don't think anybody's first reading
> of the API doc or the spec would suggest to them that if they want to
> set a wire timeout of T they actually need to call
> set_idle_timeout(T*2) on one side of the connection and it will
> magically come out as T on the other.
> Spec wording aside, does anybody actually disagree with that?
If you dont consider the spec wording, I think that an application
intent in calling a method named setIdleTimeout would likely be to
consider it as the time after which something is considered timed out
if it is idle. This is what it does now.
If we called it setOpenFrameIdleTimeout, I think they could definitely
expect it to set the value populated in the Open frame, before needing
to read the API to see when things are actually considered timed out.
If we called it setHeartbeat I think we could resonably expect folks
going either way on their thinking of what it will do before reading
the API to find out what it actually does.
In the end, its simply not the clearest area due to the spec wording,
which most users will never read, and I think its fine so long as our
methods/config actually document what they do.
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org