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

Daniil Kirilyuk commented on QPID-8772:
---------------------------------------

Thank you for your contribution.

Could you please share some details about the broker setup and workload under 
which the issue was discovered?

Have you run any performance measurements or benchmarks to measure the impact 
of these changes? If so, could you please share the results?

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

Reply via email to