[
https://issues.apache.org/jira/browse/CAMEL-23479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18081802#comment-18081802
]
Claus Ibsen commented on CAMEL-23479:
-------------------------------------
AI-assisted analysis (Claude Code on behalf of Claus Ibsen):
*Root Cause*
The bug was introduced in CAMEL-20199. The design assumes {{autoconfigure()}}
(and thus {{System.setProperty("camel.threads.virtual.enabled", "true")}}) runs
before any thread pool creation, but {{camelContext.build()}} violates that
assumption.
In {{BaseMainSupport.postProcessCamelContext()}} the execution order is:
# Line 949: {{configurePropertiesService()}} — sets up PropertiesComponent
# *Line 963: {{camelContext.build()}} — may create thread pools via
{{DefaultThreadPoolFactory}} or {{CamelThreadFactory}}, which calls
{{ThreadType.current()}} — permanently caching PLATFORM*
# Line 986: {{autoconfigure()}} reads {{camel.main.virtualThreadsEnabled}} and
calls {{System.setProperty(...)}} — *too late*
{{ThreadType.current()}} uses double-checked locking with a {{volatile static
ThreadType current}} field. Once set non-null it is never reset. Any thread
pool creation during {{build()}} fires the DCL guard before the system property
is set.
*Potential Solutions*
*Option A — Read the property early (minimal fix):*
After {{configurePropertiesService()}} (line 949) but before
{{camelContext.build()}} (line 963), load just
{{camel.main.virtualThreadsEnabled}} from the PropertiesComponent and set the
system property immediately.
*Option B — Add {{ThreadType.enable()}} static method (cleaner fix):*
Add a {{static void enable()}} method to {{ThreadType}} that directly sets
{{current = VIRTUAL}}, bypassing the system property bridge entirely. Call it
from {{BaseMainSupport}} early (before {{build()}}), and also from
{{MainConfigurationProperties.setVirtualThreadsEnabled(true)}} so programmatic
configuration also works. This aligns with removing the system property as the
communication channel between camel-main and camel-util.
*Option C — Remove the {{current}} cache:*
Remove the DCL cache from {{ThreadType.current()}} and read the system property
on every call. Since thread pool creation is infrequent (bootstrap time only),
the performance impact is minimal, and the system property set in
{{autoconfigure()}} would then be visible.
> camel-main: camel.main.virtualThreadsEnabled does not work
> ----------------------------------------------------------
>
> Key: CAMEL-23479
> URL: https://issues.apache.org/jira/browse/CAMEL-23479
> Project: Camel
> Issue Type: Bug
> Components: camel-main
> Affects Versions: 4.20.0
> Reporter: James Netherton
> Priority: Minor
> Fix For: 4.x
>
>
> Relates to changes added for CAMEL-20199.
> There are races between setting the required system property in
> BaseMainSupport here:
> [https://github.com/apache/camel/blob/05d593bc0dfe33a91d6b02285d58b09b3a717de1/core/camel-main/src/main/java/org/apache/camel/main/BaseMainSupport.java#L592-L600]
> And retrieving it in ThreadType.current() here:
> [https://github.com/apache/camel/blob/05d593bc0dfe33a91d6b02285d58b09b3a717de1/core/camel-util/src/main/java/org/apache/camel/util/concurrent/ThreadType.java#L44]
> In theory, anything could (and does) invoke ThreadType.current() before
> BaseMainSupport.autoconfigure(). Thus setting the ThreadType to the wrong
> default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
