You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by fe...@gmail.com on 2006/02/21 00:55:49 UTC
ByteBuffer Pool are never refreshed
Hi all!
I'm working now with an app. that uses many direct bytebuffer in mina, and I
have a question:
mina ByteBuffer pool are a "increase" only pool, when a new buffer is needed
if there is not another buffer in the pool, then it will be allocated.
But what happend at bytebuffers that are used once and then are forgotten
into the pool?
My problem is that my app memory usage on taskmanager always increases,
until app crashes, but my used heap memory is always the same.
So I think that all that memory can be used by direct byte buffer, but I
can't see if it is true because I have no tool to get the direct memory
usage, also with new java.lang.management.
It can be useful if mina ByteBuffer would have method that return some basic
statistics about the pool.
Maybe I'm wrong, what can I do?
thx to all!
by Fed
Re: ByteBuffer Pool are never refreshed
Posted by fe...@gmail.com.
I experienced very bad with an old implementation of SoftReferences, I don't
know if now it is different.
When I tested it on windows I saw that the "when needed" became "on every
gc".
I hope that it is resolved by now, if then it can be the right solution.
----- Original Message -----
From: "Niklas Therning" <ni...@trillian.se>
To: <mi...@directory.apache.org>
Sent: Tuesday, February 21, 2006 5:31 PM
Subject: Re: ByteBuffer Pool are never refreshed
Just a thought: How about wrapping the NIO ByteBuffer references in the
pool in SoftReferences to allow the GC the reclaim the memory when
needed? Would that be an option?
/Niklas
Fedechicco wrote:
> I modded an old 0.8 mina ByteBuffer for a previous app, and in my changes
> I
> track the fewest quantity of byteBuffer in each stack of the pool between
> two different times.
> In this way I register all over 15minutes the minimum of each stack, and
> then at the end of my 15minutes I pop out the byteBuffer unused in that
> quarter of hour. (In my case it was a good change, but you can see that
> it
> was very home-made)
>
> Specifing a max size for the pool is not an easy task because the non-sent
> data have to be put somewhere, and limit the memory for the pool means to
> limit that somewhere. I think that the way of limit the pool size must be
> developed within the overload-prevention part of MINA, because if there is
> no more memory we can only stop the producer of the data ( I mean the
> SocketIO processor and the IoHandlers ).
> Because of this I would not impose a higher limit to the pool, but I would
> provide methods to minimize it.
>
> The very last chance to reduce memory usage and buffer allocation time is
> to
> slice big buffers into many little buffers.
> The management of a similar pool cannot be a trivial thing, but there are
> many nice aspect of a similar method.
> In this way we can give gc the smallest buffers, when we have to limit the
> memory usage, because we can pretend to have them also if we have only
> biggest ones.
> Another little nice thing is that we can spend (often) less cpu time in
> expanding a buffer: by now in expanding a bytebuffer we have to call from
> the pool another buffer and copy all the data, instead with this method we
> can choose if to simply enlarge the slice, or to phisically copy in
> another
> buffer all the bytes.
>
> But I think that the mina memory management is already very very good, and
> that it don't need this radical changes.
>
> by Fed
>
--
Med vänlig hälsning
Niklas Therning
Software Architect
niklas@trillian.se
Mobil: +46 739 75 05 73
Trillian - Software Design at its best
www.trillian.se
Re: ByteBuffer Pool are never refreshed
Posted by Niklas Therning <ni...@trillian.se>.
Just a thought: How about wrapping the NIO ByteBuffer references in the
pool in SoftReferences to allow the GC the reclaim the memory when
needed? Would that be an option?
/Niklas
Fedechicco wrote:
> I modded an old 0.8 mina ByteBuffer for a previous app, and in my changes I
> track the fewest quantity of byteBuffer in each stack of the pool between
> two different times.
> In this way I register all over 15minutes the minimum of each stack, and
> then at the end of my 15minutes I pop out the byteBuffer unused in that
> quarter of hour. (In my case it was a good change, but you can see that it
> was very home-made)
>
> Specifing a max size for the pool is not an easy task because the non-sent
> data have to be put somewhere, and limit the memory for the pool means to
> limit that somewhere. I think that the way of limit the pool size must be
> developed within the overload-prevention part of MINA, because if there is
> no more memory we can only stop the producer of the data ( I mean the
> SocketIO processor and the IoHandlers ).
> Because of this I would not impose a higher limit to the pool, but I would
> provide methods to minimize it.
>
> The very last chance to reduce memory usage and buffer allocation time is to
> slice big buffers into many little buffers.
> The management of a similar pool cannot be a trivial thing, but there are
> many nice aspect of a similar method.
> In this way we can give gc the smallest buffers, when we have to limit the
> memory usage, because we can pretend to have them also if we have only
> biggest ones.
> Another little nice thing is that we can spend (often) less cpu time in
> expanding a buffer: by now in expanding a bytebuffer we have to call from
> the pool another buffer and copy all the data, instead with this method we
> can choose if to simply enlarge the slice, or to phisically copy in another
> buffer all the bytes.
>
> But I think that the mina memory management is already very very good, and
> that it don't need this radical changes.
>
> by Fed
>
--
Med vänlig hälsning
Niklas Therning
Software Architect
niklas@trillian.se
Mobil: +46 739 75 05 73
Trillian - Software Design at its best
www.trillian.se
Re: ByteBuffer Pool are never refreshed
Posted by Fedechicco <fe...@gmail.com>.
I modded an old 0.8 mina ByteBuffer for a previous app, and in my changes I
track the fewest quantity of byteBuffer in each stack of the pool between
two different times.
In this way I register all over 15minutes the minimum of each stack, and
then at the end of my 15minutes I pop out the byteBuffer unused in that
quarter of hour. (In my case it was a good change, but you can see that it
was very home-made)
Specifing a max size for the pool is not an easy task because the non-sent
data have to be put somewhere, and limit the memory for the pool means to
limit that somewhere. I think that the way of limit the pool size must be
developed within the overload-prevention part of MINA, because if there is
no more memory we can only stop the producer of the data ( I mean the
SocketIO processor and the IoHandlers ).
Because of this I would not impose a higher limit to the pool, but I would
provide methods to minimize it.
The very last chance to reduce memory usage and buffer allocation time is to
slice big buffers into many little buffers.
The management of a similar pool cannot be a trivial thing, but there are
many nice aspect of a similar method.
In this way we can give gc the smallest buffers, when we have to limit the
memory usage, because we can pretend to have them also if we have only
biggest ones.
Another little nice thing is that we can spend (often) less cpu time in
expanding a buffer: by now in expanding a bytebuffer we have to call from
the pool another buffer and copy all the data, instead with this method we
can choose if to simply enlarge the slice, or to phisically copy in another
buffer all the bytes.
But I think that the mina memory management is already very very good, and
that it don't need this radical changes.
by Fed
Re: ByteBuffer Pool are never refreshed
Posted by Chris Allen <mr...@gmail.com>.
On 2/23/06, Trustin Lee <tr...@gmail.com> wrote:
On 2/24/06, Chris Allen <mr...@gmail.com> wrote:
> I'm also curious about the new API that you proposed Trustin. Any idea
> where
> > you are with that? I'm just curious if when 1.0 comes out, is it going
> to
> > be substantially different than what we currently have in version
> 9? Just
> > curious.
>
> The new API which uses Java SPI? Users didn't like it at all and it was
> disposed. :D
>
> The API will evolve on and on until we release 1.0. IMHO, the current API
> is very concrete enough so we won't need much change. You'll be able to
> catch up the changes very easily as long as you stay tune on this mailing
> list.
This all great to know. We upgraded to version 0.9 for Red5 (
http://osflash.org/red5 ) and were hoping that we wouldn't have to change
too much when MINA 1.0 comes out. I was holding off on doing on upgrading
from 0.8 to 0.9 as I knew you guys were still discussing this API. Luke
just went ahead and did it anyway, as he needed some of the new features,
and as it turns out, it sounds like he did the right thing.
Re: ByteBuffer Pool are never refreshed
Posted by Trustin Lee <tr...@gmail.com>.
Hi Chris,
On 2/24/06, Chris Allen <mr...@gmail.com> wrote:
>
> Well Trustin,
>
> I think you are right that it doesn't make a huge difference. My problem
> ended up being caused somewhere completely different, and had nothing to
> do
> with ByteBuffer or any part of MINA. :-) Anyway, I did add the clean up
> to
> the dispose() method, and the whole thing is working great now.
It's good to hear that you found a problem. :)
I'm also curious about the new API that you proposed Trustin. Any idea where
> you are with that? I'm just curious if when 1.0 comes out, is it going to
> be substantially different than what we currently have in version 9? Just
> curious.
The new API which uses Java SPI? Users didn't like it at all and it was
disposed. :D
The API will evolve on and on until we release 1.0. IMHO, the current API
is very concrete enough so we won't need much change. You'll be able to
catch up the changes very easily as long as you stay tune on this mailing
list.
Thanks as always for creating MINA.
Thanks for using MINA. ;)
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
Re: ByteBuffer Pool are never refreshed
Posted by Chris Allen <mr...@gmail.com>.
Well Trustin,
I think you are right that it doesn't make a huge difference. My problem
ended up being caused somewhere completely different, and had nothing to do
with ByteBuffer or any part of MINA. :-) Anyway, I did add the clean up to
the dispose() method, and the whole thing is working great now.
I'm also curious about the new API that you proposed Trustin. Any idea where
you are with that? I'm just curious if when 1.0 comes out, is it going to
be substantially different than what we currently have in version 9? Just
curious.
Thanks as always for creating MINA.
-Chris
On 2/22/06, Trustin Lee <tr...@gmail.com> wrote:
>
> On 2/22/06, Chris Allen <mr...@gmail.com> wrote:
> >
> > > I suggest that you refactor your ProtocolDecoder to use
> > > CumulativeProtocolDecoder first to see if that fixes the problem.
> Maybe
> > > you're not releasing the buffers correctly?
> >
> > I think the thing that I forgot to do is to clean up the buf instance
> with
> > the dispose() method. Man I hope that's it. :-) Thanks for reminding
> me
> > of
> > your CumulativeProtocolDecoder though, as just reviewing the code made
> > this
> > clear to me.
>
>
> If you don't release the buffer, it doesn't go back to the pool. This
> means
> the buffer will be GC'd automatically once you lose its reference, so I
> think this won't make any big difference. But please let us know if any
> of
> your changes made an improvement.
>
> Thanks,
> 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
>
>
Re: ByteBuffer Pool are never refreshed
Posted by Trustin Lee <tr...@gmail.com>.
On 2/22/06, Chris Allen <mr...@gmail.com> wrote:
>
> > I suggest that you refactor your ProtocolDecoder to use
> > CumulativeProtocolDecoder first to see if that fixes the problem. Maybe
> > you're not releasing the buffers correctly?
>
> I think the thing that I forgot to do is to clean up the buf instance with
> the dispose() method. Man I hope that's it. :-) Thanks for reminding me
> of
> your CumulativeProtocolDecoder though, as just reviewing the code made
> this
> clear to me.
If you don't release the buffer, it doesn't go back to the pool. This means
the buffer will be GC'd automatically once you lose its reference, so I
think this won't make any big difference. But please let us know if any of
your changes made an improvement.
Thanks,
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
FakeSession needed
Posted by fe...@gmail.com.
Hi everybody,
I'm developing a system in wich I mux some connections received by a MINA,
to transport all the data all over another MINA and then demux it and give
the data and the events to a IoHandler.
The muxing protocol is a trivial task, but I have some problem about the
IoSession implementations.
I want to do it with filters, so I have the filter "mux and send to the real
server" and the filter "demux and give it all to the IoHandler".
Well, the filter "demux" have to take the messages that are from a single
IoSession, and demux them into different IoSession with their own
attributes, and their own local and remote socket addresses (that must be
the real InetSocketAddress).
I have many problems because I don't know how to implement this
fakeIoSession, provide the SessionManager and all that stuff, can anybody
suggest me something?
Re: ByteBuffer Pool are never refreshed
Posted by Chris Allen <mr...@gmail.com>.
On 2/21/06, Niklas Therning <ni...@trillian.se> wrote:
>
> Chris Allen wrote:
> > Hey Guys,
> >
> > It looks like I'm running into a very similar problem with my
> application,
> > at least it's similar symptoms. I think it must have to do with me
> storing
> > another ByteBuffer in the IoSession for access by all of my
> > ProtocolDecoders. It basically is there to handle the case were I get
> one
> > message sent in multiple packets and I want to wait to send the complete
> > message through to the IoHandler. I just put the incomplete message
> into
> > this ByteBuffer and when the next packet comes in (in the decode()
> method) I
> > combine the "in" ByteBuffer with the one that is in my IoSession. If
> this
> > new ByteBuffer is complete, I decode it and pass it on using out.write
> > (myCompleteMessage);
>
> FYI, there's already a ProtocolDecoder implementation included in MINA
> which does exactly what you are doing: CumulativeProtocolDecoder. Using
> that as a basis for your own ProtocolDecoder you won't have to care
> about maintaining the incomplete messages in a buffer tied to the
> session. MINA will take care of that for you.
Yeah, I knew about that one, and that is what I based my version on.
I suggest that you refactor your ProtocolDecoder to use
> CumulativeProtocolDecoder first to see if that fixes the problem. Maybe
> you're not releasing the buffers correctly?
I think the thing that I forgot to do is to clean up the buf instance with
the dispose() method. Man I hope that's it. :-) Thanks for reminding me of
your CumulativeProtocolDecoder though, as just reviewing the code made this
clear to me.
> Also, on another note, I wanted to download the source and take a look at
> > things but the SVN link listed on your site doesn't seem to work:
> >
> http://svn.apache.org/viewcvs.cgi/directory/network/trunk/?root=Apache-SVN
> > Any ideas?
>
> Sorry about that. We've had a reorganization of the svn repository since
> the last update of the web site. The correct URL is
> https://svn.apache.org/viewcvs.cgi/directory/trunks/mina/.
No problem, thanks for letting me know where I can find it.
-Chris
HTH
> /Niklas
>
Re: ByteBuffer Pool are never refreshed
Posted by Niklas Therning <ni...@trillian.se>.
Chris Allen wrote:
> Hey Guys,
>
> It looks like I'm running into a very similar problem with my application,
> at least it's similar symptoms. I think it must have to do with me storing
> another ByteBuffer in the IoSession for access by all of my
> ProtocolDecoders. It basically is there to handle the case were I get one
> message sent in multiple packets and I want to wait to send the complete
> message through to the IoHandler. I just put the incomplete message into
> this ByteBuffer and when the next packet comes in (in the decode() method) I
> combine the "in" ByteBuffer with the one that is in my IoSession. If this
> new ByteBuffer is complete, I decode it and pass it on using out.write
> (myCompleteMessage);
FYI, there's already a ProtocolDecoder implementation included in MINA
which does exactly what you are doing: CumulativeProtocolDecoder. Using
that as a basis for your own ProtocolDecoder you won't have to care
about maintaining the incomplete messages in a buffer tied to the
session. MINA will take care of that for you.
> So, with this in mind, would this patch potentially fix my issue? And if
> so, how do I go about applying it? If not, any other ideas on what might be
> going on here? I would be glad to send a more concrete example (code) if
> that will help.
The patch mentioned can, IIUC, only be used to display statistics on
things such as memory usage through JMX.
I suggest that you refactor your ProtocolDecoder to use
CumulativeProtocolDecoder first to see if that fixes the problem. Maybe
you're not releasing the buffers correctly?
> Also, on another note, I wanted to download the source and take a look at
> things but the SVN link listed on your site doesn't seem to work:
> http://svn.apache.org/viewcvs.cgi/directory/network/trunk/?root=Apache-SVN
> Any ideas?
Sorry about that. We've had a reorganization of the svn repository since
the last update of the web site. The correct URL is
https://svn.apache.org/viewcvs.cgi/directory/trunks/mina/.
HTH
/Niklas
>
> Thanks as always for your great work.
>
> -Chris
>
> On 2/20/06, Trustin Lee <tr...@gmail.com> wrote:
>
>>On 2/21/06, fedechicco@gmail.com <fe...@gmail.com> wrote:
>>
>>>Hi all!
>>>I'm working now with an app. that uses many direct bytebuffer in mina,
>>
>>and
>>
>>>I
>>>have a question:
>>>
>>>mina ByteBuffer pool are a "increase" only pool, when a new buffer is
>>>needed
>>>if there is not another buffer in the pool, then it will be allocated.
>>>But what happend at bytebuffers that are used once and then are
>>
>>forgotten
>>
>>>into the pool?
>>>
>>>My problem is that my app memory usage on taskmanager always increases,
>>>until app crashes, but my used heap memory is always the same.
>>>So I think that all that memory can be used by direct byte buffer, but I
>>>can't see if it is true because I have no tool to get the direct memory
>>>usage, also with new java.lang.management.
>>>
>>>It can be useful if mina ByteBuffer would have method that return some
>>>basic
>>>statistics about the pool.
>>>Maybe I'm wrong, what can I do?
>>
>>
>>There's a patch for this issue:
>>
>>http://issues.apache.org/jira/browse/DIRMINA-29
>>
>>But we also need to provide an efficient way to specify the maximum size
>>of
>>the pool. Any idea?
>>
>>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
>>
>>
>
>
--
Med vänlig hälsning
Niklas Therning
Software Architect
niklas@trillian.se
Mobil: +46 739 75 05 73
Trillian - Software Design at its best
www.trillian.se
Re: ByteBuffer Pool are never refreshed
Posted by Chris Allen <mr...@gmail.com>.
Hey Guys,
It looks like I'm running into a very similar problem with my application,
at least it's similar symptoms. I think it must have to do with me storing
another ByteBuffer in the IoSession for access by all of my
ProtocolDecoders. It basically is there to handle the case were I get one
message sent in multiple packets and I want to wait to send the complete
message through to the IoHandler. I just put the incomplete message into
this ByteBuffer and when the next packet comes in (in the decode() method) I
combine the "in" ByteBuffer with the one that is in my IoSession. If this
new ByteBuffer is complete, I decode it and pass it on using out.write
(myCompleteMessage);
So, with this in mind, would this patch potentially fix my issue? And if
so, how do I go about applying it? If not, any other ideas on what might be
going on here? I would be glad to send a more concrete example (code) if
that will help.
Also, on another note, I wanted to download the source and take a look at
things but the SVN link listed on your site doesn't seem to work:
http://svn.apache.org/viewcvs.cgi/directory/network/trunk/?root=Apache-SVN
Any ideas?
Thanks as always for your great work.
-Chris
On 2/20/06, Trustin Lee <tr...@gmail.com> wrote:
>
> On 2/21/06, fedechicco@gmail.com <fe...@gmail.com> wrote:
> >
> > Hi all!
> > I'm working now with an app. that uses many direct bytebuffer in mina,
> and
> > I
> > have a question:
> >
> > mina ByteBuffer pool are a "increase" only pool, when a new buffer is
> > needed
> > if there is not another buffer in the pool, then it will be allocated.
> > But what happend at bytebuffers that are used once and then are
> forgotten
> > into the pool?
> >
> > My problem is that my app memory usage on taskmanager always increases,
> > until app crashes, but my used heap memory is always the same.
> > So I think that all that memory can be used by direct byte buffer, but I
> > can't see if it is true because I have no tool to get the direct memory
> > usage, also with new java.lang.management.
> >
> > It can be useful if mina ByteBuffer would have method that return some
> > basic
> > statistics about the pool.
> > Maybe I'm wrong, what can I do?
>
>
> There's a patch for this issue:
>
> http://issues.apache.org/jira/browse/DIRMINA-29
>
> But we also need to provide an efficient way to specify the maximum size
> of
> the pool. Any idea?
>
> 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
>
>
Re: ByteBuffer Pool are never refreshed
Posted by Trustin Lee <tr...@gmail.com>.
On 2/21/06, fedechicco@gmail.com <fe...@gmail.com> wrote:
>
> Hi all!
> I'm working now with an app. that uses many direct bytebuffer in mina, and
> I
> have a question:
>
> mina ByteBuffer pool are a "increase" only pool, when a new buffer is
> needed
> if there is not another buffer in the pool, then it will be allocated.
> But what happend at bytebuffers that are used once and then are forgotten
> into the pool?
>
> My problem is that my app memory usage on taskmanager always increases,
> until app crashes, but my used heap memory is always the same.
> So I think that all that memory can be used by direct byte buffer, but I
> can't see if it is true because I have no tool to get the direct memory
> usage, also with new java.lang.management.
>
> It can be useful if mina ByteBuffer would have method that return some
> basic
> statistics about the pool.
> Maybe I'm wrong, what can I do?
There's a patch for this issue:
http://issues.apache.org/jira/browse/DIRMINA-29
But we also need to provide an efficient way to specify the maximum size of
the pool. Any idea?
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
Re: ByteBuffer Pool are never refreshed
Posted by Trustin Lee <tr...@gmail.com>.
I created a JIRA issue to track this issue. Everybody, please post your
idea here:
http://issues.apache.org/jira/browse/DIRMINA-176
I think a timeout is quite a nice way to handle this. WDYT?
Thanks,
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