what version of Weld do you use? I see that you're using GlassFish - its version would help as well.
Glassfish version - GlassFish Server Open Source Edition 4.0 (build 89)
Weld version - WELD 2.0.0 (SP1)
It would be also helpful if you provide some more info about your performance test, e.g. what components and technologies are involved, etc.
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.
Rohit, would it be possible to provide a simplified test archive (with source code) for the given test case?
This may be caused by InjectionTargets being created over and over instead of being cached. Are there any other libs used by your application?
Other libs used -
Apache commons libraries
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.
I will work on it, should have it in the first week of january
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).
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.
Alright. Has further support for glassfish been stopped?
If it has, this would influence our decision to move to another application server, maybe Wildfly
I think this is rather a question for GlassFish team - the responsible integrator.