[
https://issues.apache.org/jira/browse/CAMEL-25812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serdar Gökay reassigned CAMEL-25812:
------------------------------------
Assignee: Serdar Gökay
> camel-milo - end idle client connection threads, and give each request
> outcome a virtual thread with virtual threads
> --------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25812
> URL: https://issues.apache.org/jira/browse/CAMEL-25812
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
> Reporter: Serdar Gökay
> Assignee: Serdar Gökay
> Priority: Minor
>
> Since CAMEL-25713 (https://github.com/apache/camel/pull/28049), each
> milo-client and milo-browse connection handles the outcome of its write,
> method call, read and browse requests, and runs its reconnects, on a
> scheduled thread pool of its own with one thread per processor. As Claus
> noted in the review
> (https://github.com/apache/camel/pull/28049#discussion_r4307398068), the
> threads of a scheduled pool never end while the connection is open, and with
> virtual threads Camel's scheduled pool has a single worker.
> Measured with host JVMs, the client limited to 8 processors
> (-XX:ActiveProcessorCount=8), against a local Milo server:
> - 30 connections, idle after a load: 240 MiloClient threads, which stay until
> the connections are closed (main: none, Milo's 8 shared threads).
> - With camel.threads.virtual.enabled=true, 1 connection with 32 callers and
> 10 ms of work in the route after each awaited write: 85 exchanges/s, against
> about 670/s on main, because the routes of the connection run one at a time
> on the single worker.
> Proposal: split the two jobs. The request outcomes go to a pool whose idle
> threads end, and which starts a virtual thread for each task with virtual
> threads. The reconnects run on a single-thread scheduled executor of the
> connection. Neither executor is Milo's shared scheduled executor, so the
> CAMEL-25713 guarantee stays.
> A cached pool for the request outcomes, as suggested in the review, does not
> work with platform threads. When the connection is lost, every request in
> flight fails, and each failure waits for the lock of the connection while the
> first failure disconnects. With 4 producers sending writes that are not
> awaited, and the server frozen for 30 s, a cached pool started about 4,080
> threads, until the JVM could not create more (pthread_create failed, EAGAIN),
> and the connection was never rebuilt. With platform threads, the pool
> therefore keeps at most one thread per processor, as now, but its idle
> threads end after the keep-alive time of the default thread pool profile.
> _Claude Code on behalf of etzel-mes_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
