Yes running without NIO might narrow down.. I saw a related bug[1], but closed saying Not replicable.
1. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6208845 On Wed, Oct 15, 2008 at 12:05 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > 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 >