From: Greg W. (JIRA) <ji...@co...> - 2006-08-21 12:49:51
|
[ http://jira.codehaus.org/browse/JETTY-102?page=comments#action_72891 ] Greg Wilkins commented on JETTY-102: ------------------------------------ With out of memory errors, it is very important to realize that the code that throws the exception is not necessarily the code that is using all the memory. It may just be the unlucky bit of code that asked for more memory after something else has used up all the heap. So we have to determine what is using the memory before we can decide that it is Jetty that is leaking. It may be the application or something else that is being used. It is not as simple as direct buffers, as I have loaded tested direct buffers to high levels and observed no memory leaks However, it may well be jetty. I am re-running my long duration tests now and so far I cannot see any evidence of memory loss on 5 sites that I am running. Is it possible for you to profile these apps and see what is eating the memory? Can you catogorize the type of request that eats memory? eg static content requests, applicaton requests, JSP requests? etc. > OOM > --- > > Key: JETTY-102 > URL: http://jira.codehaus.org/browse/JETTY-102 > Project: Jetty > Issue Type: Bug > Components: NIO > Affects Versions: 6.0.0RC0, 6.0.0rc1, 6.0.0rc2 > Environment: FreeBSD 6.0-RELEASE > Java HotSpot(TM) Server VM (build diablo-1.5.0_07-b00, mixed mode) > Reporter: Artem Kozarezov > > OutOfMemoryError occurs every once in a while, following by a Denial of Service (that is, the Jetty server stops responding until it is restarted). > :WARN: handle failed > java.lang.OutOfMemoryError > at sun.misc.Unsafe.allocateMemory(Native Method) > at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:99) > at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288) > at sun.nio.ch.IOUtil.write(IOUtil.java:134) > at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:331) > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:354) > at java.nio.channels.SocketChannel.write(SocketChannel.java:360) > at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:238) > at org.mortbay.jetty.nio.HttpChannelEndPoint.flush(HttpChannelEndPoint.java:141) > at org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:754) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:321) > at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) > at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) > java.lang.OutOfMemoryError > at sun.misc.Unsafe.allocateMemory(Native Method) > at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:99) > at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288) > at sun.nio.ch.IOUtil.write(IOUtil.java:134) > at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:331) > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:354) > at java.nio.channels.SocketChannel.write(SocketChannel.java:360) > at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:238) > at org.mortbay.jetty.nio.HttpChannelEndPoint.flush(HttpChannelEndPoint.java:141) > at org.mortbay.jetty.HttpGenerator.flushBuffers(HttpGenerator.java:754) > at org.mortbay.jetty.HttpConnection.flushResponse(HttpConnection.java:480) > at org.mortbay.jetty.HttpConnection$Output.close(HttpConnection.java:711) > I suspect this is an issue described in SDN Bug 4797189: > http://bugs.sun.com/bugdatabase/view_bug.do;:WuuT?bug_id=4797189 > If so, solutions would be to provide an option not to use direct buffers (too much trouble with them, and little to no performance improvement, so, for example, Berkley DB-JE made them an option, which is by default turned off). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |