[
https://issues.apache.org/jira/browse/CAMEL-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895073#comment-17895073
]
Raymond commented on CAMEL-20199:
---------------------------------
I have a couple of questions based on this ticket:
1. When the support of virtual threads is complete, can it be considered
production-ready?
2. Is it enough to set the System Property
{{{}camel.threads.virtual.enabled{}}}={{{}true{}}} or do you also need to add
some code to enable virtual threads? (assuming JDK21+ is used).
3. When is the system property used? Only on the command line? Or is it also
possible to do this:
System.setProperty({color:#6a8759}"camel.threads.virtual.enabled"{color}{color:#cc7832},{color}{color:#6a8759}"true"{color}){color:#cc7832};{color}
Does this only work when the property is set before a new CamelContext is
created, or can it also set after it?
4. In the ticket, there is mention of semaphores to limit the amount of tasks.
Isn't it clearer to not speak of a ThreadPool when technically it uses a
different executor? For example, by using a VirtualThreadProfileBuilder and
register that, instead of a ThreadPoolProfileBuilder?
5. As virtual threads are considered lightweight, what would be considered a
good limit for tasks for a default profile? 10, 1000, 1000000? What would be
the rules to set the right profile for virtual threads?
> 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=ful}} 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)
