Hi, I'd like to modify the mina source code to reduce heap throughput. Last month, I presented on this email list the virtue of a buffer cache for a specific situation, and you have been open to hearing ideas on support. This discussion is not meant for most memory usage patterns. The memory usage pattern I have in mind is apparent in media streaming: high rate of buffer allocation/deallocation (example, 50 per second per session), very small instantaneous count of 'live' buffers (i.e, small number of buffers are referenced by the application at any moment).
First, I'd like to associate a pool or cache of buffers per session. I think I have two choices here: 1) modify the IoSession interface, 2) create a session attribute accessed using IoSession.getAttribute(). The easiest at this point is to use an attribute, but maybe you would advise against it. Second, a marcation point must be clear for when ownership of a buffer is transfered between Mina and the application. These are the rules I'm inventing: For sending, the application transfers ownership of a buffer to mina when it invokes IoSession.write, and mina transfers ownership back application when it invokes IoFilterChain.fireMessageSent. For receiving, mina transfers ownership to the application when it calls IoFilterChange.fireMessageReceived, and the application cannot return ownership to mina. Third, for Mina's receiver to obtain a buffer from the pool or cache, an interface for the pool or cache is needed. IoBufferAllocator is preferred because it will satisfy need and already exists. However, the side-effect in AbstractIoBuffer.<init>(IoBufferAllocator allocatotr, int initialCapacity) which sets the default IoBufferAllocator prevents this reuse. So, here, my choice is to either remove the side-effect or define a new interface. The easiest development path is to remove the side-effect. I have been burned by this side-effect and an happy to remove it :), but maybe you would advise against it. So, here is flow for receiving data: 1) mina's read method uses session's pool or cache to get a buffer. 2) mina's read method calls fireMessageReceive, passing up the buffer to the application. 3) the application returns the buffer to the session's pool or cache. Here is flow for sending data: 1) application uses session's pool or cache to get a buffer 2) application calls IoSession.write to send data 3) mina accesses the buffer to send data 4) mina calls fireMessageSent 5) application returns buffer to pool or cache. My intention is to run a prototype here and report to you my results. I'm open to any thoughts you may have on the above. Regards, John
