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