Skip to content

Conversation

@vy
Copy link
Member

@vy vy commented Jan 8, 2024

This PR addresses #2105 and removes log4j2.enable.threadlocals property. While doing so, following major changes are also implemented:

  • ThreadLocal-based recycler is removed
  • ParametrizedMessageFactory is removed – switched to ReusableMessageFactory everywhere
  • ThreadNameCachingStrategy is removed – Java 17 renders it redundant
  • DefaultThreadContextMap is removed – Other implementations serve fine with recyclers, which don't have any ThreadLocal issues anymore. Weirdly enough, DefaultThreadContextMap, which is the fallback used when thread locals are disabled, was using thread locals too.

Question: Similar to ParametrizedMessageFactory, I doubt if DefaultLogEventFactory makes sense anymore. Can we make the ReusableLogEventFactory default instead?

@vy vy added the enhancement Additions or updates to features label Jan 8, 2024
@vy vy added this to the 3.0.0 milestone Jan 8, 2024
@vy vy requested review from jvz and ppkarwasz January 8, 2024 19:52
@vy vy self-assigned this Jan 8, 2024
@vy vy force-pushed the main-remove-thread-locals branch from 589304f to 7177c1f Compare January 8, 2024 20:17
Copy link
Member

@jvz jvz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing diff!

Copy link
Contributor

@ppkarwasz ppkarwasz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is something I don't understand about this PR: we do want a ThreadLocalRecyclerFactoryProvider out-of-the-box.

But we want to be enabled/disabled using the Recycler.factory = "threadLocal" and Recycler.factory = "dummy" properties.

It's great you removed all the trailing ThreadLocal instances, but I think you should restore the ThreadLocalRecyclerFactory.

I am not sure what recycler factory should be the default one though: Spring Boot applications usually contain a Servlet API, but have only a single app running, so a default of threadLocal sounds good to me. If there is a way to detect the usage of virtual threads, we could switch the default to "dummy".

@vy
Copy link
Member Author

vy commented Jan 9, 2024

@ppkarwasz, I don't think you want a thread local recycler. 😜 In the face of virtual threads, thread locals are a risky liability. As a matter of fact, they already were actually; hence, several "if not running in a web application", "if only using JDK classes", etc. guards surrounding them. The new default, the queueing recycler, is almost as good as the thread local recycler. Those who need more efficiency, can use log4j-jctools too. All in all, no need for thread locals anymore really.

@vy
Copy link
Member Author

vy commented Jan 10, 2024

@ppkarwasz, I placed the thread local recycler back. I want to move on with this PR.

@vy vy merged commit 0d6876d into main Jan 10, 2024
@vy vy deleted the main-remove-thread-locals branch January 10, 2024 08:59
@ppkarwasz
Copy link
Contributor

LGTM

@vy vy mentioned this pull request Jan 10, 2024
@rgoers
Copy link
Member

rgoers commented Jan 10, 2024

I didn't see any of the doc files listed in the PR. If the property was removed it should be removed from the documentation as well.

@vy
Copy link
Member Author

vy commented Jan 15, 2024

I didn't see any of the doc files listed in the PR. If the property was removed it should be removed from the documentation as well.

Fixed in e6044c9.

@ppkarwasz ppkarwasz modified the milestones: 3.0.0, 3.0.0-beta2 Feb 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Additions or updates to features

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants