[ http://issues.apache.org/jira/browse/DIRMINA-62?page=all ]
Trustin Lee resolved DIRMINA-62:
--------------------------------
Fix Version: 0.7.3
Resolution: Fixed
Thanks for your hint! :) It was my mistake that I didn't use allocate0(). Now
I checked in the fix and deployed snapshot JARs.
> Memory 'Leak' when causing auto-expandable ByteBuffer to expand and change
> buffer-pool (stack).
> -----------------------------------------------------------------------------------------------
>
> Key: DIRMINA-62
> URL: http://issues.apache.org/jira/browse/DIRMINA-62
> Project: Directory MINA
> Type: Bug
> Versions: 0.7.2
> Environment: Non-specific.
> Reporter: Mark Atwell
> Assignee: Trustin Lee
> Fix For: 0.7.3
>
> We have been using the excellent MINA library - BTW how do you pronounce
> this: Minner? or Minor? or...?
> Anyway, we had an apparent memory leak when using the MINA code with
> auto-expandable ByteBuffers.
> I've tracked it down to the allocate/de-allocate algorithm and buffering.
> The problem is that we originally requested a small initial buffer and then
> putXXX() tons of things into it, causing it to grow. However, when the buffer
> is released (implicitly by calling ...write), the now large buffer gets
> released to a different pool (stack). Since these are unbounded, pools, the
> large-buffer pool just aggregates the big buffers - which practically never
> get used.
> I originally thought that I could just release the underlying ByteBuffer when
> the pool reaches some maximum, but no joy. It looks like I may need to rely
> on garbage-collection kicking in, but this is far from effective (For
> JavaSoft's Lame 'solution', see:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4879883 ). Why can't the
> NIO class have a deallocate/release call?! Grrrr! :o(
> I believe a better/more elegant solution may be to modify
> ByteBuffer.ensureCapacity() to also use the stack/pools rather than allocate
> more native ByteBuffers... and I guess that this would be faster also? I've
> tested this and it seems to work fine:
> The change is in ByteBuffer.ensureCapacity. Change:
> java.nio.ByteBuffer newBuf = isDirect() ?
> java.nio.ByteBuffer.allocateDirect(newCapacity) :
> java.nio.ByteBuffer.allocate(newCapacity);
> To:
> java.nio.ByteBuffer newBuf = allocate0(newCapacity,isDirect());
> Obviously one of the things one can do in the interim is work out (or
> approximate/over-estimate) the maximum buffer size, but if we want to do this
> with any degree of accuracy we need to encode our buffer first, which rather
> defeats the purpose/benefit of the ByteBuffer.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
