[
https://issues.apache.org/jira/browse/CXF-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016750#comment-13016750
]
Gregor B. Rosenauer commented on CXF-2756:
------------------------------------------
Sorry I couldn't get back on this, we couldn't spend much more time on this,
but in the end our analysis pointed in the same direction you suspected, so I
agree with your gut feeling:)
I am not using JBoss atm but suspect the situation has improved since CXF is
now the official WS stack in JBoss?
> 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
> Labels: jbossws
> Fix For: Invalid
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
