[
https://issues.apache.org/jira/browse/LOG4J2-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17628991#comment-17628991
]
Volkan Yazici commented on LOG4J2-3622:
---------------------------------------
Let's break this issue down a bit.
h1. TL usage in Log4j
Log4j uses thread locals (TLs) for two main purposes:
# efficiency (via caching)
# associating data with a thread (MDC, NDC, etc.)
h1. JEP 425 (Virtual Threads)
With JEP 425 TLs become problematic due to two main reasons:
# TLs on vthreads yield no allocation benefits since vhtreads are short-lived.
On the contrary, it becomes a redundant memory cost due to the excessive
vthread count. In this case, Log4j still works, though slower and with
increased memory footprint.
# TL mutation can be disabled for _both_ platform and virtual threads. In this
case, Log4j doesn't work, since TL access throws
{{{}UnsupportedOperationException{}}}.
h1. JEP 429 (Scoped Values)
SVs provided with JEP 429 solves the problem of associating data with a thread
(MDC, NDC, etc.) and solves it simply better.
h1. Where are we now?
* JEP 425 (Virtual Threads) has been released as a _preview_ feature in Java
19. There TL kill-switch is introduced and it is set to {{false}} by default.
* JEP 429 (Scoped Values) doesn't have any EA releases yet
* Log4j has many TL usages
h1. The (personal) conclusion
Given the current state of Log4j and Java, I don't agree with the claim of this
ticket that {_}Log4j doesn't work with virtual threads{_}.
* Log4j, or any other library in the wild that uses TLs, works in a vthread
setting. It just allocates redundant memory and runs slower.
* Setting {{disableThreadLocals=true}} and expecting Log4j to work is no
different than disabling your WiFi and expecting your browser to work.
*However,* we all agree that TLs are not a good fit for caching purposes and
cause performance regressions with vthreads. To work around this, replacing the
caching-related TL usages with the aforementioned {{Recycler}} abstraction
(used in {{{}JsonTemplateLayout{}}}) can be a way forward. Though it better be
addressed in another ticket with a more clear-cut scope: _"Replacing
caching-related thread-locals"_
How to replace the TLs used for associating data with a thread is still an
unanswered question thought. [~ckozak] and I got in touch with Loom developers
(see _"Thread-local successor for object pooling"_ threads in
[October|https://mail.openjdk.org/pipermail/loom-dev/2022-October/thread.html]
and
[November|https://mail.openjdk.org/pipermail/loom-dev/2022-November/thread.html])
to see what would be a future-proof way to implement this. As far as I am
concerned, {{disableThreadLocals}} kill-switch is still a subject of discussion
(nothing concrete yet) and SVs are not there either. Hence, there is still too
much unclarity to make any commitments yet.
> Support for virtual threads
> ---------------------------
>
> Key: LOG4J2-3622
> URL: https://issues.apache.org/jira/browse/LOG4J2-3622
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Reporter: liuxichen
> Priority: Critical
>
> I noticed in ReusableMessageFactory threadlocal are used, so If a am using
> jdk19 virtual threads while logging with threadlocal disabled,
> UnsupportedOperationException would be thrown, and using log in a lot of
> virtual threads might create a lot of useless objects, could you please fix
> this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
