users@jersey.java.net

[Jersey] Re: PermGen Leak:Each class loaded multiple times

From: Arnab Biswas <arnabbiswas1_at_gmail.com>
Date: Sun, 6 Sep 2015 08:37:34 +0530

Resending. Please let me know your suggestions (if any).

Thanks,
Arnab

On Thu, Sep 3, 2015 at 3:05 PM, Arnab Biswas <arnabbiswas1_at_gmail.com> wrote:

> Hi All,
>
> I have already posted it as an issue, reposting it to wider audience for
> your suggestion.
>
> https://java.net/jira/browse/JERSEY-2952
>
> We use Jersey Client (1.18) in our Java (1.6.0_45 32 bit)+ Tomcat (6.0.18)
> application. The dummy code is looks like the following :
>
>
> *Client client = getClientWithAuthFilter(url,timeOut);*
>
> *Client client = Client.create();*
>
> *client.setConnectTimeout(timeout);*
>
> *client.setReadTimeout(timeout);*
>
>
> *WebResource webResource = client.resource(url);*
>
> *ClientResponse response =
> webResource.accept("application/json").get(ClientResponse.class);*
>
>
> *DeviceParameterList deviceParamList = (DeviceParameterList)
> response.getEntity(className);*
>
>
> Over time, the number of classes loaded is continuously increasing. On
> enabling the class loading, unloading through JConsole (remotely), we are
> observing following logs being printed continuously (In large volume) :
>
>
> Loaded com.abc.proxy.datamodel.ResponseStatus$JaxbAccessorF_detailsCode
> from _*JVM_DefineClass*_
>
> Loaded com.abc.proxy.datamodel.ResponseStatus$JaxbAccessorF_detailsCode
> from _*JVM_DefineClass*_
>
> Loaded com.abc.proxy.datamodel.ResponseStatus$JaxbAccessorF_detailsParams
> from _*JVM_DefineClass*_
>
> Loaded com.abc.proxy.datamodel.ResponseStatus$JaxbAccessorF_message from _
> *JVM_DefineClass*_
>
> ...............................
>
> Apparently we are hitting this issue
> <https://java.net/jira/si/jira.issueviews:issue-html/JAXB-581/JAXB-581.html> related
> to JAXB (StackOverflow link here
> <http://stackoverflow.com/questions/3259291/do-i-have-a-jaxb-classloader-leak>)
> :
>
> Could some one please confirm if my assumption is correct and in Jersey
> the work around discussed has not been implemented?
>
> Also is there any other I can avoid this? Please let me know your
> suggestion.
>
> *This is little urgent as our product is hitting performance bottleneck
> because of this (possible) issue.*
>
> Thanks,
>
> Arnab
>
>
>