Luca: 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 sportsmanship. Good luck! Dan C. Wlodarski -----Original Message----- From: luca boncompagni [mailto:[email protected]] Sent: Sunday, March 13, 2016 8:41 PM To: [email protected] 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? Regards, Luca
