[
https://issues.apache.org/jira/browse/QPID-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130110#comment-18130110
]
ASF GitHub Bot commented on QPID-8772:
--------------------------------------
coolkaito commented on PR #453:
URL: https://github.com/apache/qpid-broker-j/pull/453#issuecomment-6332169855
@dakirily Thank you for the review. The AMQP 0-10 regression was addressed.
As for the heartbeat issue, I would assess the provided fix only as partial:
when write backpressure fills the output buffer, the broker can stop reading
incoming heartbeats while the read-idle timer continues running, potentially
closing an active connection.
But described behavior predates the current PR. I would suggest to fix it
with a separate JIRA and PR to keeps current CPU-spin fix focused.
> [Broker-J] Excessive CPU usage from continuous rescheduling of blocked
> TCP/TLS writes
> -------------------------------------------------------------------------------------
>
> Key: QPID-8772
> URL: https://issues.apache.org/jira/browse/QPID-8772
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-10.1.1
> Reporter: Kato Kaito
> Priority: Minor
> Fix For: qpid-java-broker-10.2.0
>
> Attachments: qpid-8772-jmh-main.zip
>
>
> Deployments with many concurrent AMQP connections can experience write
> backpressure when some clients consume data slowly or communicate over
> constrained network paths, such as VPNs or TCP proxies. In these conditions,
> outbound data remains buffered while the broker waits for clients to receive
> it.
> The native TCP/TLS transport can repeatedly reschedule a connection with
> pending output without waiting for the socket to become writable. This causes
> repeated write attempts even when the connection cannot make progress. A
> stale partial-read indication can also keep a connection scheduled when
> subsequent processing skips reads.
> This behavior can consume significant CPU despite limited network throughput
> and occupy I/O workers needed by other connections. The impact is
> particularly relevant when several slow connections share an I/O pool with
> otherwise healthy clients.
> TLS requires an additional distinction: pending application output may be
> waiting for peer handshake data rather than socket write capacity. In this
> case, write readiness cannot advance the connection; the transport must allow
> reads and wait for incoming data.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
