[ http://issues.apache.org/jira/browse/DIRMINA-176?page=comments#action_12367651 ]
Federico Bonelli commented on DIRMINA-176: ------------------------------------------ Yes, but, by the pool point of view, what is regarded as a smaller buffer and a bigger buffer? Supposing to have an application that uses 30 byte buffers and occasionally some 2kb buffers (this is the case of one of the ones I'm working on now), the pool would have serious problems to understand which ones are "smaller" and "bigger", since all of them are of the smallest or biggest size available. In this case not to cache smallest and biggest buffer is a problem, and to limit the maximum size would certainly not be an improvement. But many low-level byte protocols use short fixed lenght packets for "command" messages and use long variable lenght packets for "transport" messages, so my case is a common case. I think what you're suggesting is very good for protocols which use many different-sized buffers, and should therefore be implemented, but we should also let users chose whether to use it or not. In the overload control, we should also think about interrupting the work when the memory limit of the pool is exceeded, in order to permit the application to flush and release the buffers that haven't been written yet. > ByteBuffer pool manager which prevents endlessly increasing pool size. > ---------------------------------------------------------------------- > > Key: DIRMINA-176 > URL: http://issues.apache.org/jira/browse/DIRMINA-176 > Project: Directory MINA > Type: New Feature > Reporter: Trustin Lee > Fix For: 0.9.3 > > The current implementation of ByteBuffer pool is designed to increase its > size for ever; it doesn't decrease at all. This is often a cause of > OutOfMemoryError and unexpedly huge heap size. There's one viable solution > for this issue: > * Remove the buffers which have been unused for a long time from the pool. -- 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
