[jira] Resolved: (DIRMINA-391) Memory Leaks with SocketChannel.write

["Trustin Lee (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DIRMINA-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee resolved DIRMINA-391.
---------------------------------

    Resolution: Won't Fix

It's a known issue and that's why we suggest to use non-direct buffers.  Current JVM implementation is very unstable in managing direct buffers.  MINA committers concluded it's a flaw of JVM and JVM need to provide a proper management of the buffers.  Consequently, we switched the default buffer type to 'heap' in 2.0-SNAPSHOT and removed acquire() and release() method for better performance.

Until the JVM issue is resolved, please use non-direct buffers only and use SimpleByteBufferAllocator for maximum performance and stability.

> Memory Leaks with SocketChannel.write
> -------------------------------------
>
>                 Key: DIRMINA-391
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-391
>             Project: MINA
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 1.0.4, 1.1.1, 2.0.0-M1
>         Environment: All versions of JDK
>            Reporter: Kenji Hollis
>
> There is a known issue with Java when using the "SocketChannel.write" function with a standard ByteBuffer.  Memory gets leaked slowly as the system uses a DirectByteBuffer for each write that occurs in the system.  This may not cause an issue with systems that are under a small load, but systems under heavy load will notice a memory issue, and will eventually crash with little or no notice.
> The way  to get around this is to allocate a ByteBuffer that is allocated using "allocateDirect" first, then writing to that buffer, and clearing it out when required.  This way, you only have a single ByteBuffer that is being written to, and written from.  When the JDK sees that you are writing data from a DirectByteBuffer, it does not allocate its own DirectByteBuffer - it outputs the data from yours.  This will get around the memory allocation issue.
> So, to summarize, here's what needs to be done:
> On a write with a ByteBuffer that uses allocateDirect, this is what worked for us:
> --- Cut code ---
> private final ByteBuffer directOutputBuffer = ByteBuffer.allocateDirect(40960);
> public int write(ByteBuffer buf) {
>     directOutputBuffer.clear();
>     directOutputBuffer.put( buf.array() );
>     directOutputBuffer.flip();
>     return socket.write( directOutputBuffer );
> }
> --- End cut ---
> This will always use the allocated stack memory of 40K (which can be lower, depending on requirements of the OS based on the max output buffer size).  If you simply say "socket.write( buf )", you will notice after a short amount of time, memory usage will increase, and you will eventually get a Java exception that shows "out of memory".
> This is critical enough that it should be fixed, but as I am not a contributing member (yet), I am not sure about how to tackle this.  I believe using a pool of DirectByteBuffer objects will fix the issue, but keep in mind that if a pool is created for these, since the pool is a permanent allocation of memory, you -cannot- shrink the size of the allocated pool: you must use a static size.  The problem here will be determining which pool is in use.
> I can throw together a test case for you guys if you want to show this issue if you would like.  Please see: http://www.velocityreviews.com/forums/t147788-nio-outofmemoryexception.html for more information on the subject.  We had this issue, and have seen a fix with using this suggestion.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.