HI to all, I our application we use to cache the port, so the GC can't free memory. I used visualvm to analyze a memory dump and I find that an instance of ClientImpl is using ~700MB of retained memory.
Luca 2016-03-14 14:26 GMT+01:00 Dan Wlodarski <[email protected]>: > 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
