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
