[
https://issues.apache.org/jira/browse/QPID-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129267#comment-18129267
]
ASF GitHub Bot commented on QPID-8788:
--------------------------------------
dakirily commented on PR #463:
URL: https://github.com/apache/qpid-broker-j/pull/463#issuecomment-6297561284
Also would it be possible to add protocol level tests for AMQP 0-9-1 / AMQP
0-10 / AMQP 1-0? The change affects all protocol versions and it would be
benefitial to cover them all with tests.
> [Broker-J] Connection close can exceed the configured timeout under transport
> backpressure
> ------------------------------------------------------------------------------------------
>
> Key: QPID-8788
> URL: https://issues.apache.org/jira/browse/QPID-8788
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-10.1.1
> Reporter: Kato Kaito
> Priority: Major
> Attachments: threaddump.txt
>
>
> When an AMQP client stops reading from a native TCP/TLS connection, pending
> outgoing data can prevent the broker from completing a connection close
> requested through management. The connection can remain open beyond the
> configured connection.closeResponseTimeout, retaining resources and delaying
> administrative operations that wait for closure. If no other timeout or
> transport error intervenes, this can continue indefinitely.
> The close request is queued for processing by an I/O worker. Under
> backpressure, the transport defers pending protocol work until sufficient
> output has drained. Because the close timeout is currently armed only when
> that queued close work executes, the request can remain blocked without an
> active close deadline. Even when the deadline is armed, its expiry initiates
> normal transport shutdown, which can introduce an additional wait for
> final-write retries.
> The configured timeout should cover both sending the protocol close and
> waiting for the peer’s response, starting when closing is requested. Once it
> expires, the broker should discard remaining output, close the transport, and
> release the associated buffers. Repeated close requests should not extend the
> deadline.
> Reproduced using AMQP 0-9-1 over plain TCP with
> connection.closeResponseTimeout=2000. At 30 seconds after requesting closure
> through HTTP management, the connection remained ACTIVE, its TCP socket
> remained ESTABLISHED, and the management request was still pending. The
> attached thread dump shows the management thread waiting in
> CompletableFuture.get, reached through AbstractConfiguredObject.delete and
> LatestManagementController.delete.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
