Hi Veit That is quite impressive, great analysis.
I see Dan comments that is needed to avoid OSGI-related issues - so I think we can start from limiting that block of code to OSGI (if possible) and then see if it can be optimized. We are voting for CXF 3.1.3 but 3.0.7 has not been built yet - so may be we will have time to do something around it before 3.0.7 gets out...
The good news though it is def not OOM :-). I guess it just represents an 'extreme' case of using a given proxy, but I agree if it is possible to avoid pre-loading it all at once then it is better be avoided.
We'll have a look Thanks, Sergey On 18/09/15 16:16, Veit Guna wrote:
Hi Sergey. I compared 3.0.5 and 3.0.6 directly in GitHub and this commit caused the issue: https://github.com/apache/cxf/commit/6700967415f3e9bb1e62dcab1ea4e8660ed579b8 After removing it, compiling 3.0.6 locally and testing with it, results in a nice flat line in the class load/unload diagram. CPU usage dropped to 10% again and memory looks ok. So maybe you can figure out, what was the intention and how to avoid the loading. Maybe result caching of the already loaded classes is a solution? I'll do some additional tests though... Thanks Veit
-- Sergey Beryozkin Talend Community Coders http://coders.talend.com/
