You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Michael Bauroth <Mi...@falcom.de> on 2006/04/12 18:07:36 UTC

How to handle ByteBuffer?

Hi,

just a short question: When I use a single ProtocolDecoder in my 
FilterChain, must I consume all bytes in it? I ask because of while 
testing I realized increasing memory consumption over the time. I had 
the idea, that the ByteBuffer was eventually not cleared correctly from 
my side (I currently read only a part of the bytes in it).

That's why I ask: Can somebody explain in some short sentences, which 
part of Mina takes care of which elements (especially ByteBuffer) in 
this queue (Filter - Codec - IoSession) and which actions the user must 
do to keep the things running?

Best Regards
Michael

Re: How to handle ByteBuffer?

Posted by Trustin Lee <tr...@gmail.com>.
On 4/13/06, Michael Bauroth <Mi...@falcom.de> wrote:
>
> Hi,
>
> just a short question: When I use a single ProtocolDecoder in my
> FilterChain, must I consume all bytes in it? I ask because of while
> testing I realized increasing memory consumption over the time. I had
> the idea, that the ByteBuffer was eventually not cleared correctly from
> my side (I currently read only a part of the bytes in it).


Yes, because the data you received might contain only a part of a message.
But this is not the reason why the overall memory consumption increases.  It
is because MINA pools used buffers.  The memory usage should decrease when
server is inactive for a while by garbage collector.  If you don't want
pooling, please switch the ByteBufferAllocator by calling
ByteBuffer.setAllocator(new SimpleByteBufferAllocator()).

That's why I ask: Can somebody explain in some short sentences, which
> part of Mina takes care of which elements (especially ByteBuffer) in
> this queue (Filter - Codec - IoSession) and which actions the user must
> do to keep the things running?


The buffer for a received data is allocated by SocketIoProcessor.  It is
released in an AbstractIoFilterChain IIRC.  Therefore, basically, you don't
need to manage anything.  It is never a cause of memory leak even if the
buffers are not released.  'Release' here means that the buffer goes back to
the pool.  Buffers in the pool are not GC'd automatically.  The pool expires
aged buffers, and that's where GC kicks in.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6