[ 
https://issues.apache.org/jira/browse/QPID-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130757#comment-18130757
 ] 

ASF GitHub Bot commented on QPID-8788:
--------------------------------------

dakirily commented on PR #463:
URL: https://github.com/apache/qpid-broker-j/pull/463#issuecomment-6360285652

   CLOSE_EXISTING can still exceed the close deadline during active message 
delivery: In 
[AMQPConnection_1_0Impl.java:978–980](https://github.com/apache/qpid-broker-j/blob/4d857328d2eb4ae51028f40de2e92cff278e38cd/broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java#L978-L980),
 the deadline is started and the close task is queued, but stopConnection() is 
not called.
   
   If the existing connection has a consumer with a large backlog and 
sufficient credit, and its peer continues reading:
   
   - 
[ProcessPendingIterator.next()](https://github.com/apache/qpid-broker-j/blob/4d857328d2eb4ae51028f40de2e92cff278e38cd/broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java#L1777-L1814)
 continues to prioritise session work over the queued close task
   
   - 
[NonBlockingConnection.processPending()](https://github.com/apache/qpid-broker-j/blob/4d857328d2eb4ae51028f40de2e92cff278e38cd/broker-core/src/main/java/org/apache/qpid/server/transport/NonBlockingConnection.java#L363-L397)
 can remain in its loop as long as writes make sufficient progress
   
   - The ticker is checked before entering this loop; the deadline is not 
checked within it
   
   Consequently, although the deadline has been installed, both its enforcement 
and the close task can be delayed. Closing the existing connection and resuming 
Open on the replacement connection can therefore take longer than 
connection.closeResponseTimeout.




> [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]

Reply via email to