[
https://issues.apache.org/jira/browse/QPID-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128586#comment-18128586
]
ASF GitHub Bot commented on QPID-8788:
--------------------------------------
coolkaito opened a new pull request, #463:
URL: https://github.com/apache/qpid-broker-j/pull/463
---
**JIRA Issue**
---
[QPID-8788](https://issues.apache.org/jira/browse/QPID-8788): [Broker-J]
Connection close can exceed the configured timeout under transport backpressure
---
**PR Description**
---
The proposed change fixes connection close requests remaining pending under
outbound backpressure by starting a single monotonic deadline when closing is
requested. Aborts the transport on expiry, bounds final writes by the same
deadline, and releases queued plaintext/TLS buffers across supported AMQP
versions.
> [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]
