[JBoss JIRA] Commented: (NETTY-310) Memory leak in netty-3.2.0.BETA1.jar

[Trustin Lee (JIRA)]

    [ https://jira.jboss.org/jira/browse/NETTY-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12528562#action_12528562 ] 

Trustin Lee commented on NETTY-310:
-----------------------------------

According to the heap dump you attached, the channel's interestOps is 5 (OP_READ | OP_WRITE), which means write has been suspended because socket's send buffer is full.  That is why the requests are stuck in the queue and you are getting OOME.

It often means the client (netcat) is receiving the data slowly or the server is sending the data quickly.  What's interesting though is that this problem occurs only in 3.2.  The write throughput of 3.2 has been improved significantly, so that might be why, but I'm not completely sure because netcat is a very simple and robust application.

Unfortunately, I cannot reproduce the problem in my Linux machine.  For now, I guess it might be a Mac JDK specific issue or Mac-ported netcat issue.  Could you please run your test on Linux and let me know how to reproduce the problem?

> Memory leak in netty-3.2.0.BETA1.jar
> ------------------------------------
>
>                 Key: NETTY-310
>                 URL: https://jira.jboss.org/jira/browse/NETTY-310
>             Project: Netty
>          Issue Type: Bug
>    Affects Versions: 3.2.0.BETA1
>         Environment: $ uname -a
> Darwin hactar.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386
> $ javac -version
> javac 1.6.0_17
> $ java -version
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
> Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)
>            Reporter: Benoit Sigoure
>            Assignee: Trustin Lee
>            Priority: Blocker
>         Attachments: 3.1-gc-log.txt, 3.2-gc-log.txt, 3.2cr1-gc-log.txt, heap-3.2.0.CR1-SNAPSHOT.bz2, TestServer.java
>
>
> I'm currently writing an application against 3.2.0.BETA1 that kept dying with OutOfMemoryError.  The heap contained a very large number of objects owned by Netty (DefaultChannelFuture, LinkedTransferQueue$Node, DownstreamMessageEvent, BigEndianHeapChannelBuffer).  After being puzzled for a while, I backported it against 3.1.5.GA and the leak disappeared.  I couldn't reproduce the problem so instead I trimed down my code as much as I could and ended up with 110 lines in 4 classes, using no external dependencies other than Netty and the JDK.  When compiled and run against 3.1.5.GA, the heap size remains mostly constant.  When compiled and run against 3.2.0.BETA1, the heap keeps growing until the JVM is struggling, doing full GCs all the time.
> I'm going to attach the code and GC log to this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira