On Tuesday 14 October 2008 2:19:44 pm anoopPrasad wrote: > Dear Dan/Bharat, > > I have checked Heap,non-Heap, and perm Gen Memory usage of the process > through JCOnsole and OptimizeIT. And like Dan observed, its stable, more or > less. > (Like in the report in the first post) > > But still the OS (Solaris) reports a Resident Memory increase as well as > the swap memory increase. > > From the "pmap" report I have observed that after a number of requests a > lot of the anonymus [anon] memory blocks are allocates, which is never > reclaimed.
I have NO idea how to debug something down there. If it's outside the java heaps, it's down in native code. :-( > In the beginning we were also doubting PermGen space and Jetty server. But > it turns out that PermGen allocation is fine , no considerable > increase(~3M) at all. Right. That's what I was seeing as well. > About Jetty we are still doubtful.Since JMS transport is fine, it has to be > either Jetty problem or > the way servlets are handled in CXF Code. Well, you could TRY building a war, deploying in tomcat, and trying that. 95% of the http handling code is shared between the servlet version and the jetty version. That said, if there was an issue there, I would expect it to show up as objects on the java heap. One thing you COULD try is modify the org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine class and change the getHTTPConnectorFactory() call stuff to return the non-NIO version of the connector. It could be direct nio buffers leaking or something. > Could you please have a look at the following post and tell me whether it > applies to CXF. > http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java I don't think so. In the standalone case, nothing is being deployed/undeployed/etc.... so classes shouldn't ever need to be unloaded. Dan > > > > If it's in the process memory space, that's probably a bug in either Jetty > (nio stuff it does) or in the JDK itself. Nothing we can do about either > of those. > If we locate the problem, we can try to fix it. > > > Thank you very much. > > regards > anoopPrasad -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
