[
https://issues.apache.org/jira/browse/QPID-8680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Vavricka updated QPID-8680:
---------------------------------
Description:
[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 idle timeout is configured using the context variable
{{qpid.port.heartbeatDelay}}, the broker closes the connection if the other
peer does not send a heartbeat frame within the value specified in
{{qpid.port.heartbeatDelay}}. However, the broker should interpret the value of
{{qpid.port.heartbeatDelay}} as half of the actual timeout, as recommended by
the AMQP specification.
*Note:* The AMQP .NET Lite library (version 2.4.11) can be used to reproduce
the issue, as it sends heartbeat frames at intervals matching the idle timeout
specified in the AMQP OPEN frame.
was:
[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}
> [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 idle timeout is configured using the context variable
> {{qpid.port.heartbeatDelay}}, the broker closes the connection if the other
> peer does not send a heartbeat frame within the value specified in
> {{qpid.port.heartbeatDelay}}. However, the broker should interpret the value
> of {{qpid.port.heartbeatDelay}} as half of the actual timeout, as recommended
> by the AMQP specification.
> *Note:* The AMQP .NET Lite library (version 2.4.11) can be used to reproduce
> the issue, as it sends heartbeat frames at intervals matching the idle
> timeout specified in the AMQP OPEN frame.
--
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
