[
https://issues.apache.org/jira/browse/CAMEL-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18062670#comment-18062670
]
Guillaume Nodet commented on CAMEL-20199:
-----------------------------------------
PR #20702 (merged) addresses the ThreadLocal/ScopedValue concern:
- Introduced {{ContextValue}} abstraction that automatically uses
{{ScopedValue}} on JDK 25+ with virtual threads, falling back to
{{ThreadLocal}} on earlier JDKs (multi-release JAR)
- Migrated internal {{ThreadLocal}} usages in core (route creation context,
processor context, setupRoutes) to {{ContextValue}} with scoped API
- Added {{ThreadPerTaskSedaConsumer}} with semaphore-based concurrency
limiting for virtual-thread-per-message processing
- Deprecated {{NamedThreadLocal}} in favor of {{ContextValue}}
Remaining items for full virtual thread support:
- _JMX for {{ThreadPerTaskExecutor}}_: {{ThreadPerTaskExecutor}} is not a
{{ThreadPoolExecutor}}, so it cannot be exposed through the existing JMX
MBeans. Need a custom MBean or adapter.
- _Component-level audit_: Review third-party libraries used by components
for virtual thread compatibility (JDBC drivers, HTTP clients, messaging
libraries)
- _Connection pooling_: Verify pool implementations are VT-aware
The {{synchronized}} pinning concern is resolved by JEP 491 (JDK 24+).
> Complete support of Virtual Threads
> -----------------------------------
>
> Key: CAMEL-20199
> URL: https://issues.apache.org/jira/browse/CAMEL-20199
> Project: Camel
> Issue Type: Improvement
> Components: came-core
> Reporter: Nicolas Filotto
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: 4.x
>
>
> For full support of Virtual Threads, several sub-tasks need to be done:
> * Avoid Lengthy and Frequent Pinning by replacing synchronized blocks with
> ReentrantLocks (use the option {{-Djdk.tracePinnedThreads=full}} to print
> stack traces when a thread blocks while pinned)
> * Don't Cache Expensive Reusable Objects in Thread-Local Variables by
> avoiding thread locals when possible since when using Virtual Threads, the
> objects will never be reused so if the thread-local variables are never
> reset, it will end up with an OOME.
> * Use Semaphores to Limit Concurrency instead of relying on the size of the
> thread pool when applicable
> * Allow to expose {{ThreadPerTaskExecutor}} through JMX indeed so far it is
> limited to {{ThreadPoolExecutor}}
> References
> [https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
