Serdar Gökay created CAMEL-25812:
------------------------------------
Summary: 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
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)
