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
