[
https://issues.apache.org/jira/browse/QPID-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130421#comment-18130421
]
ASF GitHub Bot commented on QPID-8772:
--------------------------------------
dakirily commented on PR #453:
URL: https://github.com/apache/qpid-broker-j/pull/453#issuecomment-6345812189
I agree that the heartbeat issue can be fixed with the follow-up JIRA / PR
to keep this change focused. Feel free to create such follow-up JIRA. As for
this change I would ask you to verify the new unit tests - some of them have
Thread.sleep() calls, which I would prefer to avoid. Please replace those calls
with countdown latches or other java concurrency utilities to make the tests
deterministic. Otherwise I have no further comments.
> [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]
