[
https://issues.apache.org/jira/browse/QPID-8680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17910723#comment-17910723
]
Robbie Gemmell commented on QPID-8680:
--------------------------------------
This one is arguably doing what it should, as a nuance of what is being
configured versus what the protocol defines, and when the different protocols
were supported.
The configuration is originally from the 0-x days and is not directly the
timeout, but for the heartbeat period. In the older protocols, the heartbeating
was negotiated to a single value and was defined based on when a heartbeat was
to be sent, __ i.e the \{_}'heartbeat delay'{_}. There was also a statement
that the connection be closed if 2 heartbeat periods passed without traffic. (I
believe the broker has a config to toggle that also, though defaults to 2).
In contrast, AMQP 1.0 defined independent idle-timeouts notified in each
direction, and recommends (whereas, it should really have required) advertising
half of your actual timeout to avoid spurious timeouts. So arguably,
advertising the heartbeat delay exactly as the idle-timeout, is what it should
do for this 'heartbeat delay' based configuration. It should _additionally_
treat that as being half the actual timeout, so the improvement should probably
instead be making it do that if it isnt currently.
> [Broker-J] Halve the configured idle timeout
> --------------------------------------------
>
> Key: QPID-8680
> URL: https://issues.apache.org/jira/browse/QPID-8680
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Tomas Vavricka
> Priority: Minor
> Fix For: qpid-java-broker-9.2.1
>
>
> [AMQP 1.0
> specification|https://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf]
> in Chapter 2.4.5 states '{_}Connections are subject to an idle timeout
> threshold. The timeout is triggered by a local peer when no frames{_} _are
> received after a threshold value is exceeded. The idle timeout is measured in
> milliseconds, and starts from_ _the time the last frame is received. If the
> threshold is exceeded, then a peer SHOULD try to gracefully close the_
> _connection using a close frame with an error explaining why. If the remote
> peer does not respond gracefully within_ _a threshold to this, then the peer
> MAY close the TCP socket._ _Each peer has its own (independent) idle timeout.
> At connection open each peer communicates the maximum_ _period between
> activity (frames) on the connection that it desires from its partner.The open
> frame carries the idletime-out field for this purpose. *To avoid spurious
> timeouts, the value in idle-time-out SHOULD be half the peer’s*_ {*}_actual
> timeout threshold._{*}'
> When the incoming idle timeout is configured using the context variable
> {{{}qpid.port.heartbeatDelay{}}}, the idle timeout value sent in the AMQP
> Open frame is not halved, as recommended by the AMQP specification.
> For example, if {{qpid.port.heartbeatDelay}} is set to 60, the Open frame
> sends an idle timeout value of 60000.
> {noformat}
> 09:28:32.118 [AmqpProvider :(1):[amqp://localhost:20405]] TRACE
> org.apache.qpid.jms.provider.amqp.FRAMES – [896644936:0] RECV: Open{
> containerId='10a79ad9-ae87-414b-b557-393547c7f932', hostname='null',
> maxFrameSize=262144, channelMax=254, idleTimeOut=60000, outgoingLocales=null,
> incomingLocales=null, offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
> sole-connection-for-container], desiredCapabilities=null,
> properties={product=Apache Qpid Broker-J Core, version=9.2.0,
> qpid.build=0a84538aee48598d57df9550312554b92a2b5f6d,
> qpid.instance_name=test-broker, qpid.virtualhost_properties_supported=true,
> sole-connection-detection-policy=0}}
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
