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


>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.

Reply via email to