"이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote:
<snip/>
So my question :
- why do we flush the data after having encoded them instead of passing
the newly created message (the encoded data) to the nextFilter ?
It seems to be superfluous.
The two code blocks above are effectively same. The reason we call
filterWrite once more with an empty buffer (MessageByteBuffer or
MessageWriteRequest) is to generate a proper messageSent event which
corresponds to the written message. Let me know if there's more
efficient way to take care of messageSent events.
I have no idea atm, but from the top of my head, as the data has already
been flushed, I don't see any reason to send another message (empty)
just in order to get a MessageSent event generated. As soon as the last
byte of data has been flushed, the next thing to do is to generate this
event. I still have to go through the code to see if it can be
implemented or not (my knowledge is really limited here...)
Another question, which is related to this part of code : what if the
client is slow and cannot read the data fast enough ? It seems that the
server may simply put all the data to be sent in a big queue, whatever
the client does, instead of flushing new data as soon as the client has
read the previous data.
It can really break the server if a client request a big chunk of data
but never read it. Usually, what you do in a server is to build the
response on the fly, but if you can split the response as small chuncks
and submit them one by one, waiting for the client to process them
before sending more, you will protect the server.
Am I totally wrong, or such a mechanism is already in place in MINA ?
You might be interested in the following question from Gaston Dombiak:
http://markmail.org/message/uylaf2zauta6ppe7
And there's an answer there in my response made at 9 Apr 2008.
After having read the thread, I see that this issue is something some
other users have experimented (the slow client).
Checking on the number of bytes written or number of message sent is not
really a good idea, has it will rely on a polling mechanism. What would
be better is to pass a callback to the write method, callback called
when the last byte has been sent. In this way, the caller will be
reactive instead of being active. It might be a extension of the current
API which would be valuable.
wdyt ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
