Re: Using RecyclerFactory throughout the code base

I did not understand your remark about benchmarks. The recycling strategies are there mostly to address memory concerns, not performance. For instance, thread-locals are not a preferable option for apps that run on hundreds of threads, which is the case in most Tomcat apps. Or am I missing a point

Re: Using RecyclerFactory throughout the code base

I like the idea, but I defer to the benchmark results for this sort of thing ;-) The ability to bound reusable objects below the thread count will become more valuable when project loom[1] is released, as the JVM will support millions of virtual threads on a handful of OS threads. This will make

Re: Log4j JSON layout template Uris enum

Replaced all "enum" singletons with "[static] final class"es in both master and release-2.x. On Wed, Nov 18, 2020 at 2:04 PM Gary Gregory wrote: > Hi Volkan, > > I think the strength of the feelings in my argument was more of a > reflection on my frustration of my lack of involvement in this new

Using RecyclerFactory throughout the code base

Hello, As you might have already known, JSON template layout uses RecyclerFactory for recycling objects to maintain a certain memory footprint, that is, work garbage-free. By default there are 3 recycler factory implementations shipped: dummy, thread-local, and queue. (See the relevant part of the

LOG4J2-2850 Sporious LocalizedMessageFactoryTest failures

After merging GitHub PR #436 , LocalizedMessageFactoryTest started to fail randomly: - Broken GitHub Actions build - Broken Jenkins build