Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Classloader leak can lead to PermGen/Metaspace OutOfMemoryError #104
I'm using logstash-gelf-1.11.0 configured via biz.paluch.logging.gelf.log4j.GelfLogAppender and deployed with war. As the application server is used Wildfly 10.1 but it must be reproduced in any server with worker pool.
After send log messages and redeploy application classes cannot be garbage collected due to ThreadLocal's that hold reference on custom class:
I think the simplest solution is not to use ThreadLocal's for these cases and always create objects or implement ObjectPool.
If don't use ThreadLocal's then will be some performance degradation (actually such result is not representative due to big errors).
When logstash-gelf.buffer.size=0 and logstash-gelf.message.pooling=false leak doesn't reproduced, but can the setting of these parameters lead to performance degradation and increase count of objects?
Using an object pool requires several invasive changes and tbh runtime class reloading isn't something that is in the primary usage scope. Disabling pooling/buffering falls back to performance characteristics of 1.10 with the difference that 1.11 uses an own, improved JSON encoder.
added a commit
Mar 15, 2017
I pushed an updated version of the library with configurable pooling options via
Instance-held pools can consume more memory initially but the ClassLoader leak should be fixed. Care to give
Although I set logstash-gelf.message.pooling to false, I am still having problem when redeploying in Tomcat (failure of garbage collection due to GelfUDPSender pooling threads).
I explicitly call
with no success.
Do have any idea how I can overcome this?
Thanks in advance.
(I use version 1.11.2)