[
https://issues.apache.org/jira/browse/CAMEL-22839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051190#comment-18051190
]
Claus Ibsen commented on CAMEL-22839:
-------------------------------------
See also PR
https://github.com/apache/camel/pull/20702
> [camel-core] Thread Local consistency implementation
> ----------------------------------------------------
>
> Key: CAMEL-22839
> URL: https://issues.apache.org/jira/browse/CAMEL-22839
> Project: Camel
> Issue Type: Improvement
> Reporter: Pasquale Congiusti
> Priority: Minor
>
> Reporting this as a potential feature request for the future, low priority
> and with a deeper design analysis required. While working on certain
> technology which leverage the Java Thread Local storage (opentelemetry, mdc),
> I bumped in a common problem which we managed to workaround for now. However,
> in order to have a cleaner design we may need to understand how to change
> Camel core design to address properly the usage of Thread Local based
> technologies.
> This is a low priority, as, Thread Local may be replaced in the future by
> Scoped Values instead and it may break inadvertently existing business logic.
> Important to evaluate the tradeoff and the potential risk.
> The problem is that as we reuse threads at runtime we may be in the situation
> that a work started in a Thread, can be finished in another thread. Then, the
> latter may be reused to start yet another work. This is an old solid design
> which is working and giving Camel excellent performances. However we're
> missing the possibility to reset potential Thread Local values which were
> used in a previous work.
> In order to have a consistent and Thread Local safe design we can think to
> introduce any mechanism (ie, some method interface) to allow any usage of
> Thread Local to safely reset the status when the work is completed. We may
> change the CamelInternalProcessor java class implementation to introduce such
> a mechanism and analyze how to properly extend it to let either the user or
> the components making use of Thread Local to provide the necessary clean
> before switching to next job.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
