gmiscione commented on issue #3819: URL: https://github.com/apache/logging-log4j2/issues/3819#issuecomment-3068154118
I am no expert in low latency programming, but the use case you are describing makes perfect sense. I don't know if Logback has support for something similar to this pooling that can help in similar cases. Regarding the last sentence, I think that in this case the problem is more about who "owns" the threads for which the ThreadLocal are allocating values rather than which classloader loaded the classes. In my scenario, the threads owning the pooled value are the Tomcat's worker threads, the ones used by Tomcat to handle the generation of a response to an http request. In my case, I have no control over those threads in my application. This is in contrast with the case, for example, where the application itself allocates a thread pool of workers that can then benefit of pooling and that can be easily cleaned up when necessary. Given that, I would even more lean toward the minimalistic solution, where the value `Constants.ENABLE_THREADLOCALS` actually controls if the ThreadLocal is used or not. In that way, scenarios that could leverage on pooling and reusing objects will benefit of the reduced generation of memory garbage. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
