11:20 a.m.
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
Priority: Critical
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
12:09 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Max Rydahl Andersen commented on HHH-2481:
------------------------------------------
testcase + patch ?
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
Priority: Critical
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
2:34 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2481) Big memory leak in the use of CGLIB
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=all ]
Paul Malolepsy updated HHH-2481:
--------------------------------
Attachment: fix.diff
Here is a diff of the fix for this issue as well as a test case.
Just to give an idea of how potentially bad this leak was, making this change had a
dramatic impact on the the memory use and performance of our servlet based web
application. Before, we had to max out the Xmx of our servlets at 2gb, and even still
we'd get OOM errors after about 6 hours under heavy stress testing. Now they run fine
at 500mb. This has also translated to some astonishing performance gains in the overall
performance of our app. I'd be very interested to see if other people have a similar
experience.
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
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
12:42 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Paul Malolepsy commented on HHH-2481:
-------------------------------------
For those who want to fix this issue without waiting for this fix, or making a custom
build of hibernate, here is a workaround you can implement in your own code. This code
should go after you create a Configuration object and before you create the
SessionFactory:
{code:title=Bar.java|borderStyle=solid}
//assumes an instantiated Configuration variable called cfg
cfg.setListeners("load", new LoadEventListener [] {new
DefaultLoadEventListener(), new LoadEventListener() {
public void onLoad(LoadEvent event, LoadType loadType) throws
HibernateException {
Object obj = event.getResult();
if (obj instanceof HibernateProxy) {
Enhancer.registerCallbacks(obj.getClass(),null);
}
}
}});
{code}
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
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
2:51 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Max Rydahl Andersen commented on HHH-2481:
------------------------------------------
thanks for the patch and related testcase; but a more interesting testcase would be a test
that actually showed the OOME. Are you saying that simply creating and closing a
SessionFactory in multiple threads will do it ?
And i'm a bit troubled on how setting the callback will actually affect future
instantiation.
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
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
2:53 a.m.
New subject: [Hibernate-JIRA] Assigned: (HHH-2481) Big memory leak in the use of CGLIB
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=all ]
Max Rydahl Andersen reassigned HHH-2481:
----------------------------------------
Assign To: Scott Marlow
Scott, you have had fun with this before - could you verify/fix it ?
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
1:17 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Paul Malolepsy commented on HHH-2481:
-------------------------------------
The test case demonstraits that during the course of normal operation, a fully hydrated
object managed by hibernate is stuck in static memory. Creating any proxy object on any
given thread will cause this behavior. How much memory this leaks, and weather or not
you get an OOM is dependent on:
1) How many proxy types your application has.
2) How many threads you create proxies on.
3) Most importantly, how large the object graph is that is attached to these proxy
objects.
To create a test case that shows the OOM is very easy, but coming up with a test case that
actually asserts if there is an imminent OOM is next to impossible in Java. But the OOM
is just a symptom of the real issue which is hydrated objects stuck in memory. This alone
should be a giant red flag.
As far as future instantiations, there should be no worry here. Any time a proxy is ever
instantiated, it is always preceded by the Enhancer.registerCallbacks() method. In fact,
the callback object is directly tied to the instance of the proxy being created so if this
callback object was ever used by future instantiations, that would be a very bad thing.
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
1:54 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Scott Marlow commented on HHH-2481:
-----------------------------------
Paul,
Thanks for submitting the problem, fix and test.
Scott
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
9:48 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Scott Marlow commented on HHH-2481:
-----------------------------------
My next step is to evaluate whether we could fix the root issue differently (or work
around it), that being HHH-1293. In the original code, we passed the instance in directly
which didn't always work on some platforms (especially Linux). At the very least, we
should clear the ThreadLocalStorage reference before returning as your patch does.
In your example above, is the potential of the leak really that high? I wouldn't
expect 15,000 objects leaked. Correct me if I'm wrong, but I would expect one TLS
slot per thread to hold a reference. If you have 100 threads, that is a max of 100
objects leaked. Unless a collection is stored in each TLS slot and then the potential is
higher. Either way, we should fix the leak.
http://forum.hibernate.org/viewtopic.php?t=947902 seems to discuss this issue as well.
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
11:13 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
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
10:35 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2481) Big memory leak in the use of CGLIB
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=c...
]
Scott Marlow commented on HHH-2481:
-----------------------------------
The fix looks good (except we use hard tabs instead of spaces but no big deal).
We used to pass in the callback directly until we hit HHH-1293. Registering the callback,
works around HHH-1293, but not clearing the TLS caused this Jira.
I'll check the fix into trunk and the 3_2 branch soon.
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
11:16 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-2481) Big memory leak in the use of CGLIB
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=all ]
Scott Marlow resolved HHH-2481:
-------------------------------
Resolution: Fixed
Fix Version: 3.2.3
Fix checked into 3_2 branch and trunk.
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
Fix For: 3.2.3
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
6491
days inactive
6500
days old
hibernate-issues@lists.jboss.org
11 comments
3 participants
participants (3)
-
Max Rydahl Andersen (JIRA) -
Paul Malolepsy (JIRA)
-
Scott Marlow (JIRA)