users@jersey.java.net

[Jersey] Re: Memory leak with SystemDescriptor

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 29 Apr 2015 13:33:21 +0200

Hi Veit,

It would be good if you could provide a concrete reproducer test for your problem. I’m not able to infer the necessary details about your use case from your description. Hard to look into the issue without having the full context.

Marek

> On 29 Apr 2015, at 12:23, Veit Guna <Veit.Guna_at_gmx.de> wrote:
>
> Hi.
>
> I've digged deeper into the rabbit hole and came to the same results as reported here:
>
> https://java.net/jira/browse/JERSEY-2800
>
> It also got filled up with @BeanParams classes.
>
> Then I switched to 2.17 and found out, that my @BeanParam class (PathContext) is missing some functionality.
> It looks like that:
>
> public class PathContext {
>
> @PathParam(TenantResource.TENANT_ID_PATH_PARAM)
> private String tenantId;
> @PathParam(AccountResource.ACCOUNT_ID_PATH_PARAM)
> private String accountId;
> @PathParam(RepositoryResource.REPOSITORY_ID_PATH_PARAM)
> private String repositoryId;
> @PathParam(RepositoryEntryResource.REPOSITORY_ENTRY_ID_PATH_PARAM)
> private String repositoryEntryId;
> ....
>
> With 2.16 and prior, Calling a URL like this:
>
> http://localhost:8080/something/api/1/tenants/b38c7e6b-f17f-45bf-a746-65b40f95d845/repositories/1ee83a90-6e2f-435c-ac6a-ece0f5106671/entries
>
> Resulted into filled tenantId and repositoryId.
>
> Now, only tenantId is filled - although repositoryId should also be accessible.
> I can also confirm, that now only one instance of PathContext is created (using @PostConstruct).
> With 2.16 it were 3: 1st with only tenantId set, the other 2 instances had repositoryId correctly set.
>
> PathContext is injected into different resources as field member. Resources are accessed via Subresourcelocators.
> So I'm wondering if the fix from JERSEY-2800 maybe broke some other stuff?
>
> I would expect, if I inject the PathContext anywhere, it should parse the complete URL for the specified @PathParams.
> This didn't seem to happen anymore.
>
> Can someone confirm this?
>
> Thanks!
> Veit
>
>
>
> Gesendet: Mittwoch, 29. April 2015 um 08:48 Uhr
> Von: "Veit Guna" <Veit.Guna_at_gmx.de>
> An: users_at_jersey.java.net
> Betreff: [Jersey] Memory leak with SystemDescriptor
> Hi.
>
> We're using Jersey 2.16 with JDK 1.7.0_55-b13 64 bit and Tomcat 7.0.21 under Windows 7 to build a REST api.
> Now, we're facing a problem with memory usage during load. We've created a TestNG testcase method, that
> performs CRUD operations 10 times in a loop. That method is invoked 1000 times by 50 concurrent threads.
>
> After approx. 30 minutes, the server gets slower and slower until it gets an OutOfMemoryException. We
> created a ThreadDump with jvisualvm and used Eclipse Memory Analyzer to get to the root problem.
>
> It seems that hk2's SystemDescriptor is eating memory like a boss :). Here's the output of the analyzer:
>
> 170.088 instances of "org.jvnet.hk2.internal.SystemDescriptor",
> loaded by "org.apache.catalina.loader.WebappClassLoader @ 0xc026bd80"
> occupy 625.581.408 (92,47%) bytes.
> These instances are referenced from one instance of "org.jvnet.hk2.internal.ServiceLocatorImpl",
> loaded by "org.apache.catalina.loader.WebappClassLoader @ 0xc026bd80"
>
> We already found an old JIRA ticket regarding a SystemDescriptor memory leak:
>
> https://java.net/jira/browse/HK2-205
>
> that was fixed in 2.3.0.
>
> So we switched to the latest hk2 version, 2.4.0-b16. But without any effect.
>
> We're wondering what SystemDescriptor is used for and why it is eating so much memory.
>
> Does anyone have deeper insights?
>
> Thanks!
> Veit