[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Paul Malolepsy commented on HHH-2481:
-------------------------------------
Yep, that thread discusses this issue exactly.
I'm afraid the leak is as large as I stated. The static thread local is created on
*each* proxy type. So if my application has a Customer class and a Order class, each type
has their own static thread local, and the last proxy object created of each type on each
thread will be leaked.
RE: fixing the issue differently. That occurred to me too. I though you might just be
able to call one of the Enhancer.create() methods which let you pass in the callback
directly, but I figured there must have been a reason why that wasn't chosen (sounds
like I was right) so I decided to respect the original design. But one little extra call
to clear the thread local should be a pretty minimal impact.
Big memory leak in the use of CGLIB
-----------------------------------
Key: HHH-2481
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate 3.2.2
MySQL 5.1
Reporter: Paul Malolepsy
Assignee: Scott Marlow
Priority: Critical
Attachments: fix.diff
Original Estimate: 5 minutes
Remaining: 5 minutes
The way CGLIBLazyInitializer is creating proxies is resulting in a potentially massive
memory leak.
In CGLIBLazyInitializer.getProxy() just before the proxy is instantiated, a call is made
to Enhancer.registerCallbacks() passing in the instance of CGLIBLazyInitializer that will
manage the proxy. This variable is stored in a static ThreadLocal on the CGLIB created
persistentClass so that any subsequent objects instantiated will get this callback class.
The problem is that once this ThreadLocal is set, it is never cleared, so it will stay
around (together with the object it's managing, and whatever object graph it may be
connected to) until the next time a proxy is created for that type on that thread.
For our application we have about 150 different proxy types, and our app can have over
100 threads. This results in potentially 15,000 proxy objects and their graphs stuck in
memory.
The fix for this is simple. Just make another call the Enhancer.registerCallbacks() with
a null callback arg, right after the proxy class is instantiated:
Enhancer.registerCallbacks(factory, null);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira