[
https://issues.apache.org/jira/browse/CXF-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855813#action_12855813
]
Daniel Kulp commented on CXF-2756:
----------------------------------
Any chance this can be tested with a straight CXF war in tomcat?
The problem with this test case is that the problem could be either in CXF or
it could be in the JBoss "glue" layer that is part of the JBoss J2EE layers
that scans the ears and such and calls off to the CXF calls. For example, they
could be holding onto factories or something that would prevent things from
being GC'd.
I'm not saying it's NOT cxf, but my gut feeling says this is in JBoss. The
JAX-WS TCK that we run deploys 100+ wars with their own wsdl's and such (in
tomcat) and hits them pretty hard and I haven't seen any major issues.
> OutOfMemoryError with many service endpoints
> --------------------------------------------
>
> Key: CXF-2756
> URL: https://issues.apache.org/jira/browse/CXF-2756
> Project: CXF
> Issue Type: Bug
> Components: Bus
> Affects Versions: 2.2.5
> Environment: Windows 7 x64 Sun JDK 1.6.0_17-b04), Java HotSpot(TM)
> 64-Bit Server VM (build 14.3-b01, mixed mod;
> IBM J9 JDK 64bit IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc64-64
> jvmap6460sr5
> JBoss 5.1.0.GA + JBossWS-CXF 3.2.2.GA
> Reporter: Gregor B. Rosenauer
> Attachments: memory-usage_cxf.png, memory-usage_metro.png,
> stresstest-ear.ear
>
>
> I am deploying an EAR in JBoss which exposes many (approx. 120) endpoints,
> each of those publish a simple WSDL (2 services with 1 parameter) - demo
> attached, if necessary I can add a private attachment with the real world EAR.
> When invoking these service endpoints, CXF always scans the entire EAR and
> (re)builds the service endpoint registry.
> Performance with many (10-20) concurrent service calls degrades and memory
> consumption increases steadily, ultimately leading to an OutOfMemoryException
> in JBoss. It seems the endpoints cannot be found in the cache and so the
> entire registry is rebuilt.
> In a simple test it showed that simply displaying the service endpoints
> exposed WSDL is sufficient to trigger the problematic behaviour:
> {code:title=JBoss server.log|borderStyle=solid}
> 2010-04-06 10:47:34,861 DEBUG
> [org.springframework.beans.factory.support.DefaultListableBeanFactory]
> Invoking init method 'publish' on bean with name 'Vvpvzfpr'
> 2010-04-06 10:47:34,862 INFO
> [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] Creating
> Service {http://vvpvzfpr.vvp.ta2mig.itsv.at/}VvpvzfprService from class
> at.itsv.ta2mig.vvp.vvpvzfpr.IVvpvzfpr
> 2010-04-06 10:47:34,868 INFO [org.apache.cxf.endpoint.ServerImpl] Setting
> the server's publish address to be
> http://127.0.0.1:8080/ta2mig-vvptest1-ear-ta2mig-vvptest1-service-BUILD/Vvpvzfpr
> 2010-04-06 10:47:34,871 INFO
> [org.apache.cxf.common.injection.ResourceInjector] failed to resolve resource
> at.itsv.ta2mig.vvp.vvpvzfpr.Vvpvzfpr/connectionFactory
> 2010-04-06 10:47:34,872 DEBUG
> [org.springframework.beans.factory.support.DefaultListableBeanFactory]
> Finished creating instance of bean 'Vvpvzfpr'
> {code}
> This is for every service at every call, please ignore the "failed to resolve
> resource ..." as the datasource is not available in the local test
> environment.
> Metro does not show this behaviour and reacts very fast with minimum memory
> consumption, but we cannot easily switch the entire web service stack at this
> time and I don't believe CXF has such a problem with many service
> endpoints... however since even calling the WSDL from JBoss' web interface
> triggers the problem, the app cannot be blamed...
> Memory analysis with Eclipse MAT shows that the class
> org.apache.cxf.common.util.CacheMap grows excessively large, will attach some
> screenshots (also tested with jVisualVM) and logs later.
> Possibly related bugs:
> Memory Leak in WSDLManagerImpl - SchemaCacheMap
> CXF-1621
> Memory leak due to literal keys in WSDLDefinition map
> CXF-1639
> performance of repeated calls to jaxws.Service.createPort is poor, jaxb
> context is created every time
> CXF-850
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
