cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Wlodarski <>
Subject RE: ClientImpl responseContext momory consumption
Date Mon, 14 Mar 2016 13:26:27 GMT

I'm new to this mailing list, but pretty old hat at Java and OOP. Please allow me to take
a general stab at this issue.

CXF is Java-based, so when the requestContext object is "destroyed" it's actually just marked
for release and its related variable made invalid (i.e. nullified, typically). The GC should
come around and clean it up when the memory is needed. But it's certainly no longer available
in its original scope.

On the other hand, are you sure the code supporting the requestContext is actually loading
the entire response at once? Have you profiled CXF's space performance while responding to
this service? Java buffers are pretty dang smart.

Finally, there's always adding a System.gc() call, but this is generally considered very poor

Good luck!
Dan C. Wlodarski

-----Original Message-----
From: luca boncompagni [] 
Sent: Sunday, March 13, 2016 8:41 PM
Subject: ClientImpl responseContext momory consumption

Hi to all,

I'm using cxf 3.1.4 shipped by wildfly 10. I  have to call a service with very large response
(~ 10Mb). My app is a web-app and in my wildfly has ~ 300 thread.

If I understand correctly the code, ClientImpl.responseContext is cleaned only on destroy,
so, the full response (~10Mb) is in the responseContext for each thread that makes a call
to the large response service. So, if every thread of my application server does a call to
the service, I need 3000Mb for storing requestContext.

If I understand correctly the code, how can I free memory after calling the service?

View raw message