mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Heath <mhe...@apache.org>
Subject Re: how to guarantee flushed write in encoder - mina-2.0.0-M1-snapshot
Date Fri, 05 Oct 2007 21:44:03 GMT
ubaggili wrote:
<snip>

> Mina 1.X had a different implementation of the "out.write()" as it seemed
> flush those in a timely manner.  Mina 2.x's implementation seems to want to
> optimize all write requests that are part of the response and groups/merges
> them together at times but not other times.  Even if I "pause" for 5 seconds
> between write requests, it is not until the messageReceived method exits
> that the buffers are flushed - or so it seems.  In other words, the
> underlying nio buffer doesn't get written to until that whole chunk of code
> completes.
> It would be nice if there is a setting that can allow for the mina 1.x style
> writing.
> 
> Any thoughts on this would be greatly appreciated.  Even if the
> implementation of the sequence outlined above can be performed though other
> mechanisms using filters, ioHandlers, etc..  The only requirement that I
> have is to use the same channel to the client to feed back requests and
> receive the corresponding responses.

When MINA 2.0 writes pending messages, it loops until either all the 
pending message have been written to the OS or until it can't send any 
more data without blocking because the OS' write buffer for the socket 
is full.  So, MINA is receiving each of your individual ByteBuffer (now 
IoBuffer) objects and writing them in rapid succession.  This allows the 
operating system to send all the data in a single IP packet regardless 
of the tcpnodelay setting.  MINA is not doing any mering of your 
messages.  The operating system is doing this.  IIRC, MINA 1.x will 
write a ByteBuffer and then resume writing once the data in the 
ByteBuffer is flushed by the OS.  So, MINA 2.0 is much more efficient 
and can more effectively use the OS' write buffer.

As Niklas was saying, you should not have a protocol that depends on TCP 
packet boundaries which is what you appear to be doing.  It is perfectly 
valid for routers and proxies to concatenate or split TCP packets.  So 
when Server X or Client Y receives a packet and a messageReceived event 
is triggered, per your example, it is possible that the received 
ByteBuffer contains multiple requests or responses.

You can not assume that 3 IoSession.write()'s will result in 3 
messageReceived events on the remote host.  n IoSession.write()'s will 
result in m messageReceived events on the remote host and m can be ANY 
number greater than 1.  That means that a single IoSession.write() could 
result in multiple messageReceived events or multiple 
IoSession.write()'s could result in a single messageReceived event. 
And, of course, it is possible (and often common) for m and n to be equal.

You do bring up a good point that you can't flush the write queue from 
within messageReceived.  I'll file a JIRA issue for this.

I hope this clarifies things.  If you still have questions or if I'm 
still not understanding your problem, please let us know.


-Mike

Mime
View raw message