[ 
https://issues.apache.org/jira/browse/LOG4J2-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14939389#comment-14939389
 ] 

Gary Gregory commented on LOG4J2-1142:
--------------------------------------

I took a very brief look (it's late here, sorry), a new ObjectPool class and 
new StringBuilderPool class does not make it simpler than a ThreadLocal. It's 
not what I'd naturally come up with unless you were specifically addressing the 
web container use case. Then as you mentioned, there's OSGi, no time to dig 
into that one now.

When you say "Your object has a reference to its classLoader" do you mean 
because an Object points to its class (getClass()), which in turns points to 
its class loader?

And the wep app has classes with Loggers which have Appenders which have 
Layouts and here we are.

When an app is undeployed, is there anything we can provide to unload the right 
logger context? Or are we out of luck because we do not know which thread's 
ThreadLocals to remove()?

Yes, I'd like to see what Remko sees performance wise if he can set up some 
tests.

> ThreadLocals in Layout implementations should be non-static to prevent memory 
> leaks in web containers
> -----------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1142
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1142
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Layouts
>    Affects Versions: 2.4
>            Reporter: Dmitri Blinov
>            Assignee: Remko Popma
>             Fix For: 2.4.1
>
>         Attachments: LOG4J2-1142.patch
>
>
> As discussed in LOG4J2-1125, storing ThreadLocal<StringBuilder> in a static 
> field may not interact well with the thread pools and class loaders of some 
> web containers and may result in memory leaks, especially in older web 
> containers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to