Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CGLIB PermGen memory leaks under Karaf [SPR-10573] #15202

Closed
spring-projects-issues opened this issue May 19, 2013 · 2 comments
Closed

CGLIB PermGen memory leaks under Karaf [SPR-10573] #15202

spring-projects-issues opened this issue May 19, 2013 · 2 comments
Assignees
Labels
in: core status: declined

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented May 19, 2013

Tim Jones opened SPR-10573 and commented

There appears to be an issue with the use of CGLIB and permgen class loader leaks. Attached is a zip file containing some tests that can be run in a Karaf container that highlight this issue. I have also added a few observations of my own.

In summary I have set up 2 bundles, with one bundle exporting a transaction manager and the other bundle referencing the transaction manager with a class that has been transactionally advised via a @Transactional annotation.

The tests are further divided with one group dependent on Spring 3.1.4 and the second group dependent on Spring 3.2.2. Within these two groups there are two referencing bundles, one that is coded against interfaces (=> JDK proxy) and the other without interfaces (=> CGLIB).

Both the Spring 3.1.4 and Spring 3.2.2 test bundles that use interfaces seem to be fine, i.e. the referencing bundle can be loaded and unloaded many times without resulting in a OutOfMemoryError: PermGen space error. I was able to verify using JVisualVM that the classes are collected although there seems to be a difference as to when they are collected (details of which are in the readme of the zip).

Both the Spring 3.1.4 and Spring 3.2.2 test bundles that do not use interfaces and hence CGLIB comes into play ultimately fail with a OutOfMemoryError: PermGen space error. I was able to verify using JVisualVM that the classes are not collected and that after uninstalling the referencing bundle that instances of the test classes still remain.

It is possible that the tests could be simplified further, perhaps one bundle rather than two would suffice but I think separating the transaction manager is more realistic.

I realise that class loader permgen leaks are an old well trodden issue that came to the forefront when undeploying web apps but because OSGI permits breaking an application down into fine grained modules I think this issue will become even more apparent as the promise of undeploying/stopping/starting parts of an application becomes a significant driver for the adoption of OSGI.

I hope this helps.

Regards,

Tim


Affects: 3.2.2

Reference URL: https://jira.springsource.org/browse/SPR-8190

Attachments:

Issue Links:

  • #18506 Upgrade to CGLIB 3.2.2

1 votes, 7 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 20, 2014

Juergen Hoeller commented

Let's mark this as "Won't Fix" from a Spring Framework perspective since there is nothing we intend to do as a follow-up in the core framework here...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 20, 2014

Tim Jones commented

I had raised the issue here as I thought the Spring Framework had repackaged CGLIB internally http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/migration-3.2.html. Admittedly if this is the case and the prime motive for packaging CGLIB was to ensure no classpath conflicts with other third party frameworks then I can understand your reluctance to spend time fixing what you would probably argue is an issue with CGLIB not the Spring Framework. However from an end user's point of view we receive 'Spring code' that is packaged with a known issue.

Although I have provided a reproducible test based on OSGI which may or may not be something that fits the strategic Spring direction, the same issue will be felt by undeploying/deploying on Web servers or other (a search on google will highlight many instances of CGLIB as the cause of permgen leaks).

Perhaps the Spring team could keep in mind to look at permgen leaks if migration to an alternative e.g. Objenesis is looked at?

@spring-projects-issues spring-projects-issues added type: bug status: declined in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: bug label Jan 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: declined
Projects
None yet
Development

No branches or pull requests

2 participants