cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregor B. Rosenauer (JIRA)" <>
Subject [jira] [Commented] (CXF-2756) OutOfMemoryError with many service endpoints
Date Thu, 07 Apr 2011 08:04:06 GMT


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:
>             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 []
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 {}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
> 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 []
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
> 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:

View raw message