[
https://issues.apache.org/jira/browse/QPID-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132442#comment-18132442
]
ASF GitHub Bot commented on QPID-8788:
--------------------------------------
dakirily commented on PR #463:
URL: https://github.com/apache/qpid-broker-j/pull/463#issuecomment-6418226295
NonBlockingConnection.doWork() checks the deadline before doRead(), but
calls doWrite() unconditionally afterwards. Processing an incoming Close can
start the deadline during the read. With connection.closeResponseTimeout = 0,
that deadline has already expired when the handler returns, yet a write is
still attempted. Likewise, an abort() during the read does not prevent this
write.
Please recheck the deadline and closed state after doRead(), abort on
expiry, and skip normal writes once closed. Graceful flushing can remain in
shutdownFinalWrite().
The existing peer-close test invokes the close handler before doWork(), so
it misses this path.
> [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
> Fix For: qpid-java-broker-10.2.0
>
> 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
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
