Memory leak caused by retained instances of BeanManagerImpl / WeldInterceptorClassMetadata

[rohit.gupta]

We use CDI extensively in our application.
On performance testing, we see a lot of instances of WeldInterceptorClassMetaData retained in the heap.
This is residing in the old generation and does not let the GC reclaim any memory. The application stops responding after this point

The CDI scopes used in the application -
RequestScope
SessionScope
ViewScope

We also use a lot of CDI injection

Would love any pointers as haven't been able to turn up anything on this so far.

[mkouba]

Hi Rohit,

what version of Weld do you use? I see that you're using GlassFish - its version would help as well.

[rohit.gupta]

Hi Martin,

Glassfish version - GlassFish Server Open Source Edition  4.0  (build 89)

Weld version - WELD 2.0.0 (SP1)

Thanks

[mkouba]

Could you try to upgrade to the latest Weld 2.0.x (2.0.4.Final at the moment) - i.e. simply replace the file weld-osgi-bundle.jar in your GF installation with this one. WELD-1478 (fixed in 2.0.4.Final) might be related.

[mkouba]

It would be also helpful if you provide some more info about your performance test, e.g. what components and technologies are involved, etc.

[rohit.gupta]

Hi Martin,

I upgraded to WELD 2.0.4.Final , but I still have the memory leak.

Information about the performance test -

Application Components and Technologies used - JSF Mojarra 2.2.0 and EJB's

The application uses CGI injection to get resources. Also used extensively are the CDI scopes.

Performance test structure - Login - Navigate - Logout (Nothing too complex here)

Test Results -

The test simulates 5 users logged in and and performing the same test sequence 40 times.

The first test run which generates 2000 requests goes fine.

The second test run hangs as there is no more memory available.

The profiler shows Memory usage in the Old Generation gradually go up. During the second test run, the old generation fills up due to too many instances of org.jboss.weld.bean.interceptor.WeldInterceptorClassMetadata. These instances remain in memory even after the test is halted. 3000 requests lead to ~~ 147MB being help in Heap with these instances.

Let me know if you need any more data.

Cheers

Rohit

[mkouba]

Rohit, would it be possible to provide a simplified test archive (with source code) for the given test case?

[jharting]

This may be caused by InjectionTargets being created over and over instead of being cached. Are there any other libs used by your application?

[rohit.gupta]

Hi Josef,

Other libs used -

Apache commons libraries

poi:3.9

poi-ooxml:3.9

poi-ooxmk-schemas:3.9

Arquilian

dom4j:1.6.1

fop:0.94

eclipselink:2.5.0

Could you explain to me about the injection targets being used instead of cached.

For me, I use the annotation @Inject and CDI provides me with the resources to be injected.

Thanks

[rohit.gupta]

I will work on it, should have it in the first week of january

[mkouba]

Rohit, simplified test case would definitely help us to confirm our hypothesis. Also a fix mentioned in WELD-1564 (which should prevent further mem leaks but will not improve GlassFish integration code efficiency) should be included in a planned 2.0.5.Final release (compatible with GlassFish4).

[rohit.gupta]

Martin, Replacing the OSGI bundle does not work for upgrading to 2.1.0.

Are there any other steps required?

Also, I have a Test Harness ready which replicates the issue.

You can find it at https://dl.dropboxusercontent.com/u/90469849/TestHarness/TestHarness.rar

The test harness includes a Maven project and a JMETER project to execute the tests.

Thanks

[mkouba]

Rohit, you can't upgrade to Weld 2.1.x - it's not compatible with GlassFish4. However the fix is also included in 2.0.5.Final.

[rohit.gupta]

Alright. Has further support for glassfish been stopped?

If it has, this would influence our decision to move to another application server, maybe Wildfly

[mkouba]

I think this is rather a question for GlassFish team - the responsible integrator.