[jira] [Assigned] (CAMEL-25812) camel-milo - end idle client connection threads, and give each request outcome a virtual thread with virtual threads

["Serdar Gökay (Jira)" <ji...@apache.org>]

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