You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Stefan Schubert (JIRA)" <ji...@apache.org> on 2010/08/12 23:26:16 UTC
[jira] Created: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
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.
[jira] Commented: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913980#action_12913980 ]
Sergey Beryozkin commented on CXF-2939:
---------------------------------------
Are you referring to CXF JAXRS frontend ? In 2.2.10, JAXBElementProvider does not use WeakHashMaps...
> 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.
[jira] Commented: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Rob Neild (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913974#action_12913974 ]
Rob Neild commented on CXF-2939:
--------------------------------
The project I work on has the CXF libraries in the tomcat "shared/lib" area.
When I upgraded to 2.2.10, restarting WARs in tomcat was broken (JAXBContextImpl.getBeanInfo generates exceptions saying it can't find beans)
On investigation I found that with a WeakHashMap, JAXBContext is rebuild when a WAR was stopped and started.
But using a HashMap means JAXBContext isn't re-created on a application restart
I am guessing people would advise the CXF libraries not be put into the shared classloader area "shared/lib" and should be in each individual application WAR?
> 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.
[jira] Updated: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Stefan Schubert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Schubert updated CXF-2939:
---------------------------------
Attachment: removed_weak_hash_maps.patch
This patch just changes WeakHashMaps to HashMaps in two lines. I did not write any tests as testing GC behaviour seemed a little ridiculous to me and the interface to create the JAXBContext is a static. Should I refactor anything that this is testable? Nevertheless testing if the GC doesn't throw away any Map entries sounds funny :-)
But I executed the tests nonetheless.
> 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
> 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.
[jira] Resolved: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-2939.
------------------------------
Assignee: Daniel Kulp
Fix Version/s: 2.2.10
Resolution: Fixed
> 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.
[jira] Commented: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914234#action_12914234 ]
Daniel Kulp commented on CXF-2939:
----------------------------------
Well, CXF needs to work as a shared library. In an OSGi environment, CXF would be another bundle deployed in the OSGi container and thus must be sharable. Thus, if there are bugs, we need to get them fixed.
> 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.
[jira] Commented: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Stefan Schubert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914057#action_12914057 ]
Stefan Schubert commented on CXF-2939:
--------------------------------------
Does CXF work as a shared lib anyway? Can I deploy a second Webapp using CXF and it works with the shared lib? If not, we should not do anything to enable this.
If yes, you can think about a shutdown or refresh hook. As far as I know CXF already listens to Spring framework application events. If it is shutting down or refreshing, you could simply evict the context specific caches. Just look at org.apache.cxf.transport.servlet.CXFServlet#onApplicationEvent which is already doing maintenance work on refreshes. It could probably do more
> 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.
[jira] Commented: (CXF-2939) Permgen Leak in JAXB due to recreation
of JAXBContexts in CXF
Posted by "Stefan Schubert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913983#action_12913983 ]
Stefan Schubert commented on CXF-2939:
--------------------------------------
Yeah, Sergey - and that is the problem, as I understand it.
Rob, this reads like a class-loader problem. CXF accesses application specific ressources like annotated beans etc. So it is not really a shared library like log4j or an Oracle jdbc driver for example, which have no runtime dependencies to your web application but only are service dependencies.
Sorry to say that, but I would not put CXF into 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.