My web service client application uses Apache CXF to generate client stubs for talking to several web services. The generated CXF web service stub objects have quite a large memory footprint (10 - 15 web service objects take more than 64 MB of memory). Is there any way to reduce the CXF object footprint?
21
votes
why do you think it those objects exactly that are taking up the memory?
– Bozho
I did some crude profiling (watching process memory size in the Windows Task Manager). Created a test app, that in a loop, creates instances of the web service stubs and binds to the web service. Each time a binding occurs another 5 - 10k of memory are used. The web service itself has about 360 web methods.
– Jeremy Raymond
That's not an appropriate approach to memory profiling. Take a heap dump and analyze it using VisualVM. That may mean it's consuming 5-10kb, but it should be virtually all garbage collectable memory, so it's ready there waiting to be freed. Java will free it when it needs it or when it otherwise decides to GC. 5-10kb is not so excessive if the service invokations are churning through a lot of XML.
– squawknull
@squawknull: I have WebService proxies managed by Spring context (scope=singleton). That means I need them all the time when my service is deployed. More over it takes about a second to create each of them – luxury I cannot afford for online application if I create them on demand. Heap analysis showed that the memory is inefficiently used and can't be GC'ed. @all: I have created java.net/jira/browse/JAX_WS-942 – please vote for it.
– dma_k
Not that my comment is any solution, but 360 web methods on a single endpoint is a huge lot. Certainly goes against most best practices for Web Services (keep surface area small, single responsibility principle, cohesion etc.) I don't want to be in your shoes when the contract changes slightly and you need to regenerate stubs etc.
– jbx
3 Answers
1
votes
We had similar problems with Axis. The problem we had was that we wanted to do many concurrent calls to the web service and the Axis clients generated using the WSDL caused each client to use a lot of memory. The clients arent thread safe, so we had to create one client per request.
We had two choices. First we could prune the generated code - but that was not nice for maintenance reasons.
Second, we simply pruned the WSDL to remove the parts that were not relevant to us, and regenerated slimmed down clients. That way, if we called one service method, it's client wouldn't contain bulk for unrelated methods which that thread wouldn't be using.
Worked quite well, but is still a maintenance nightmare, because any time the WSDL gets updated (e.g. our partner releases a new version of their web service), we need to spend time creating cut down wsdls. The ideal solution I guess would be to get our partner to recognise our problems and take ownership of the cut down WSDLs.
0
votes
We took a different approach to the CXF client. I haven't looked into its memory footprint, which isn't an issue in our context, but it's certainly a simpler method of development than creating stubs. It looks something like this:
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
factory.setAddress(endpoint);
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
factory.setServiceClass(myInterface.class);
Object client = factory.create();
((BindingProvider) client).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);
myInterface stub = (myInterface)client;
We just do that (of course we've built some utility classes to simplify things further) for any WS we want to hook up to at runtime (provided, of course, we have its Java interface). Our goal was to make the whole WS thing as transparent to the programmers as possible. We really have no interest in WSDLs and XSDs per se. We suspect that we're not alone.
