cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chester Kim (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-6642) Memory Leak in ResponseImpl.readEntity()
Date Thu, 15 Oct 2015 16:40:05 GMT

    [ https://issues.apache.org/jira/browse/CXF-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959170#comment-14959170
] 

Chester Kim edited comment on CXF-6642 at 10/15/15 4:39 PM:
------------------------------------------------------------

[~sergeyb] Yes.  The leakage doesn't happen when I didn't use threadpool (serviceexecutor).
 It seems like CXF uses Spring to resolve the context which always store things in ThreadLocal
of a task in its own threadpool.   Also, it's not only problem with GET method.  We're using
JAX-RS 2 client api for all of GET/HEAD/PUT/POST/DELETE.  So, your suggested solution might
not be a case for others, does it?

I'll definitely try the fix when 3.1.4 comes out.
Thanks!


was (Author: violkim):
[~sergeyb] Yes.  The leakage doesn't happen when I didn't use threadpool (serviceexecutor).
 It seems like CXF uses Spring to resolve the context which always store things in ThreadLocal
of a task in its own threadpool.   Also, it's not only problem with GET method.  We're using
JAX-RS 2 client api for all of GET/HEAD/PUT/POST/DELETE.  So, your suggested solution might
not be a case for others, does it?

> Memory Leak in ResponseImpl.readEntity()
> ----------------------------------------
>
>                 Key: CXF-6642
>                 URL: https://issues.apache.org/jira/browse/CXF-6642
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.1.2, 3.1.3
>         Environment: Mac OS X 10.10.5, Spring 4.2.0
>            Reporter: Chester Kim
>            Assignee: Sergey Beryozkin
>            Priority: Critical
>              Labels: client, cxf
>             Fix For: 3.0.7, 3.1.4
>
>
> Massive number of ResponseImpl instances are not garbage collected after calling readEntity.
 By looking at VisualVM, it seems like those are indirectly referred by something stored in
ThreadLocal which is used by context resolving and never been removed after all.   Our production
instance actually caused OutOfMemory errors after this.   It might be related to https://issues.apache.org/jira/browse/CXF-6458
and looks simiar to https://java.net/jira/browse/JERSEY-2463 but not sure.  Note this only
happens when I used thread pool.
> My workaround was bypassing readEntity() and deal with inputstream directly like following
which is not quite desirable but works for now.
> {code}
>     private static Response copy(Response response) {
>         return Optional.ofNullable(response)
>                 .map(r -> r.getEntity())
>                 .filter(e -> e instanceof InputStream)
>                 .map(is -> newResponse(response.getStatus(), (InputStream)is))
>                 .orElse(response);
>     }
>     private static Response newResponse(int status, InputStream is) {
>         Response response = Response.serverError().build();
>         try {
>             String payload = IOUtils.toString(is);
>             response = Response.status(status).entity(payload).build();
>         } catch (IOException e) {
>             log.error("Failed to read entity from response", e);
>         } finally {
>             try {
>                 is.close();
>             } catch (IOException e) {
>                 log.error("Failed to close InputStream after reading entity from response",
e);
>             }
>         }
>         return response;
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message