mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Message-less, non-flooding I/O mode
Date Wed, 06 Oct 2010 14:55:32 GMT
  On 10/6/10 2:49 PM, Oleg Kalnichevski wrote:
> MINA devs,
> Would you be receptive to the idea of supporting a message-less (or
> bare-metal, if you like) I/O mode? Essentially, I would like MINA 3.0 to
> make it possible to interact directly with the underlying I/O channels
> bypassing the read / write data queues altogether.
There is nothing such as a queue used for read operation. We read the 
data from the channel into a buffer, and then call the messageReceived() 
method through the filters chain up to he handler.

Of course, if you add an executor in the middle, then that's a different 

Anyway. Maybe what you want is that the handler directly do the read, 
sparing the creation of an intermediate buffer. You can't currently do 
that, so the buffer will always be created and filled with data.

For the write operation, what is currently missing in MINA 2 is the 
transfertTo method which would allow you to push file contents directly 
to the socket without copying it into memory. This is most certainly 
something we want to have in 3.0

> In other words,
> whenever a channel signals read / write readiness, the I/O selector
> thread would fire an event referring to the originating channel. The
> decision as to how much data can be read from or written to the channel
> would be left up to the I/O handler.

Well, that does not seems very useful. If you defer to the handler the 
read and write operation on top of the channel, then why not directly 
write your NIO server from scratch ? It's about 500 lines of code, all 
in all, and you can even disassemble MINA to do that ...
> I am perfectly aware of downsides of this approach, which are several,
> but it would enable data intensive protocols such as HTTP and SMTP to
> manage connection memory footprint more conservatively. For instance,
> the protocol handler could attempt to preallocate a fixed and invariable
> amount memory at the connection initialization time and either succeed
> or fail early instead of risking the out of memory condition half way
> through a transaction due to the memory flooding.
You already can manage the flooding by limitating the number of bytes 
you read. As you have the complete control on the initial RcvBufferSize, 
plus the control over the created buffer, you can always at some point 
'kill' a session which has receive too much data.

There is also possible to manage a threshold for every session, which 
might help in this case.

For instance, in Apache DirectoryServer, we have added a parameter that 
limit the size of the received PDU, this parameter can be modified for 
any session. If we receive more bytes that this limit, then we close the 
session. It works pretty well.
> I understand this might be too much of a radical shift from the existing
> architecture, so feel free to ignore me if you find this approach
> incompatible with the MINA 3.0 design concepts.
No, that's fine, it's just important to know what we already have and 
what we can offer without cutting two legs to MINA :)

Emmanuel L├ęcharny

View raw message