[
https://issues.apache.org/jira/browse/QPID-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124227#comment-18124227
]
ASF GitHub Bot commented on QPID-8772:
--------------------------------------
coolkaito opened a new pull request, #453:
URL: https://github.com/apache/qpid-broker-j/pull/453
**JIRA Issue**
[QPID-8772](https://issues.apache.org/jira/browse/QPID-8772): [Broker-J]
Excessive CPU usage from continuous rescheduling of blocked TCP/TLS writes
**PR Description**
The proposed change updates scheduling to:
- Wait for socket write readiness when output is blocked, instead of
immediately rescheduling solely because output remains pending.
- Wait for peer input when TLS requires an unwrap operation, after buffered
handshake output has been flushed.
- Clear the partial-read indication at the start of each processing pass.
- Keep consumers marked as transport-blocked until pending output drains.
- Resume suspended protocol work when writes can progress, including when
output drains within the same processing pass.
The expected result is lower CPU consumption under write backpressure and
improved availability of I/O workers for other connections.
> [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
>
> 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
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
