What steps will reproduce the problem?
1. From within a thread pool (e.g. Executors.newFixedThreadPool(64)) , create
ClassLoader from keyczar jar, use loaded class to do a keyczar operation that
uses GSON parser
2. Repeat 1 on other threads in thread pool (by repeatedly resubmitting that
task to the pool)
3. Watch JVM crash "with java.lang.OutOfMemoryError: PermGen space"
What version of the product are you using? On what operating system?
keyczar-0.71f-060112.jar, Mac OS X 10.8.4
Please provide any additional information below.
The use of ThreadLocals creates leaks when Keyczar is used in a thread pool.
Each thread in the pool acquires its own value for the ThreadLocal, blocking
the entire ClassLoader that loaded Keyczar from ever being garbage collected.
This is particularly a problem in application containers, which expect to use
new ClassLoaders to support subsequent deploys (or rapid development). When
Keyczar is used in an environment like this (such as GlassFish or Tomcat), the
JVM will fail with an OutOfMemory error due to insufficient PermGen space.
Does the caching of a GsonBuilder have a significant impact on performance? Why
not reallocate one each time gson() is called?
Original issue reported on code.google.com by adam.bou...@gmail.com on 12 Sep 2013 at 6:38
Original issue reported on code.google.com by
adam.bou...@gmail.comon 12 Sep 2013 at 6:38