On 10/6/10 6:43 PM, Oleg Kalnichevski wrote:
Use MemoryMappedFile. It's supported.
Errr. Thank you very much.
:)
This is just an example, by here, you can perfectly do something like :
do {
WriteFuture future = session.write( data);
future.await();
if ( !future.isWritten() ) {
// error
break;
}
// grab next piece of data
} while ( true );
The whole point is that I would like to write out only as much data as a
channel is able to take _without_ blocking. This is precisely what the
Channel interface enables me to do. I do not want just to block waiting
for a chunk of memory to be written out.
Here, MINA won't help. We don't generate an event when the socket is
ready to be written, and this is probably wrong. It would b *way* better
to be able to inform the handler that it can send a new piece of data,
you are plain right. And that could perfectly be something we want to do
in MINA 3.0
Currently, as I said in my first mail, written messages are enqueued,
waiting to be sent. This is really an issue if you have tons of messages
to send (we already experienced OOM due to this 'design' and the only
way to bypass this problem was to wait for the previous message to be
completely sent (ie, wait on the future).
I ear you on that...
I would very much rather prefer to avoid memory flooding instead of
having to manage it.
There is no way you can 'avoid' memory flooding, except if you limit
everything :
- the message size
- the number of connected clients
which is, somehow, managing the flooding.
I respectfully disagree. One can use a fixed size input / output session
buffers and suspend / resume the channel using interest ops whenever
session buffers get full / empty all _without_ allocating any extra bit
of memory on the transport level. Believe me, it works quite well.
Thanks to the Channel interface.
see my previous point. I know understand your issue, and I agree that
MINA is not solving it atm, so yes, we can provide the interface you
need for MINA 3.0.
Very interesting thread !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
