2.4.5 Idle Timeout Of A Connection
"To avoid spurious timeouts, the value in idle-time-out SHOULD be half the
peer's actual timeout threshold"
So, to me, this means on the @open performative the client should flow (e.g.,)
30000 as the idleTimeOut it would like to negotiate, but should actually only
enforce that data is received from the other end within 60000 milliseconds
before it closes the session+connection.
However, if that is the case, then the code in proton-c (pn_tick_amqp in
transport.c) and proton-j (#tick() in TransportImpl.java) would appear to be
doing the wrong thing?
Currently it *halves* the advertised remote_idle_timeout of the peer in order
to determine what deadline to adhere to for sending empty keepalive frames to
the remote end.
Similarly it uses its local_idle_timeout as-is to determine if the remote end
hasn't send data recently enough (closing the link with resource-limit-exceeded
when the deadline elapses). This would seem to mean that empty frames are being
sent twice as often as they need to be, and resource-limit-exceeded is being
fired too soon.
It seems to me that instead it should used remote_idle_timeout as-is for
determining the deadline for sending data, and the local_idle_timeout specified
by the client user should either be doubled when determining the deadline or
halved before sending it in the @open frame.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU