mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [3.0] IoBuffer
Date Sun, 13 Dec 2009 05:01:33 GMT

On Dec 12, 2009, at 5:15 PM, Bogdan Ciprian Pistol wrote:

> Hello all,
> A discussion on the https://issues.apache.org/jira/browse/DIRMINA-751
> arose that is more appropriate here on the ML.
> Emmanuel Lecharny said:
> "Some thoughts :
> - in MINA 3.0, the IoBuffer class will probably be removed, or
> refactored, as we don't really need all this mechanism, but this is
> more something we should discuss on the ML.
> - the class hierarchy is probably overkilling. We should have a
> IoBuffer interface, an AbstractIoBuffer abstract class, move the
> IoBufferWrapper and ProxyHandshakeIoBuffer classes to be subclasses of
> the AbstractIoBuffer class.
> - I'm not convinced that using the CachedBuffer brings any speed
> improvement. Trying to be smarter than the VM is most certainly a lost
> of time... IMO, this class should be removed. "
> I understand the performance of the new IoBuffer 3.0 that will have a
> list of ByteBuffers
> (http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design) so
> will provide a continuous stream of bytes that spans several
> ByteBuffers (zero copy on auto-resize, just add a one more ByteBuffer
> to the list in the IoBuffer), but when writing the list of ByteBuffers
> out on the network, how do you want to do it? I understand that the
> gathered write has some problems in JDK, I heard some rumors about
> this, for example:
> http://lists.jboss.org/pipermail/netty-users/2009-July/000939.html
> Though I did not tested personally if there is a problem with  
> gathered writes.

I'd like to see some hard numbers on these.  I have respect for these  
people's opinions but I know that in my case I have been coding around  
old performance issues that are no longer an issue.  I'm happy to  
write some benchmark code and run it against the machines I have  
access too, i.e, Mac OS X, Linux, and Solaris.


View raw message