cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2939) Permgen Leak in JAXB due to recreation of JAXBContexts in CXF
Date Thu, 23 Sep 2010 12:09:49 GMT

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

Sergey Beryozkin commented on CXF-2939:
---------------------------------------

Hmm...

So we've solved one problem but have introduced another one...

To be honest - this is not the problem of the CXF but that of JAXBElementProvider - quickly
rebuilding the one from source and replacing HashMap with WeakHashMap will do it if the weak
map is expected.

But there must be a better way to choose between HashMaps and WeakHashMaps if it is what is
needed to help users to put the cxf  into the shared lib  

> Permgen Leak in JAXB due to recreation of JAXBContexts in CXF
> -------------------------------------------------------------
>
>                 Key: CXF-2939
>                 URL: https://issues.apache.org/jira/browse/CXF-2939
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.1.5
>            Reporter: Stefan Schubert
>            Assignee: Daniel Kulp
>             Fix For: 2.2.10
>
>         Attachments: removed_weak_hash_maps.patch
>
>
> From http://cxf.547215.n5.nabble.com/REST-web-service-loading-many-classes-for-each-request-CXF-2-2-6-and-jaxb-impl-2-1-5-td2266472.html#a2266472:
> If a GC occurs, WeakRefs throw away the JAXBContext. So on the next occasion (where occasion
could be one of billions of calls to a CXF/JAXB api) the JAXBContext has to be rebuilt from
scratch. 
> JAXB (specifically com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector) calls com.sun.xml.bind.v2.runtime.reflect.opt.Injector#find
to try, if it already created a field or method accessor class. If not it injects a new one
into the class loader via com.sun.xml.bind.v2.runtime.reflect.opt.Injector#inject. 
> The problem is now that #inject caches the generated accessor in the Injector and find
only looks into the Injector (and never again into the class loader, where it used to define
the class). But once a GC occurs the Injector throws itself away, too (caching itself in some
weak map). 
> So it happens that each REST api call after a GC occurred a hundred new classes are created
by JAXB - because JAXB on low-level forgets the classes it defines (and keeps them on high-level)
and CXF forgets the JAXBContext so that the high-level memory of JAXB is erased as well. 
> There are four possible solutions: 
>  - Fix the Injector: Actually very easy and my favorite solution. Just let the Injector
look into the class loader as well when it cannot find the class in its own memory. BUT to
have a bug fixed in JAXB actually sounds scary, how long would that take to get into a version?)

>  - Enable CXF to keep only one JAXB context (and not to throw it away) - do not know
how to do that 
>  - Use a workaround to disable bytecode generation by JAXB (-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true)
--> disables the whole bytecode magic Injector stuff and just does reflection - probably
with a slight performance impact 
>  - Do not use JAXB with CXF on a website with significant load 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message