While dealing with some of our committer issue, I have found that the
ProtocolCodecFilter may have something wrong in the way it send messages
to client.
I'm using MINA 1.1.6
Here is the code :
ProtocolCodecFilter.filterWrite() {
...
ProtocolEncoder encoder = getEncoder(session);
ProtocolEncoderOutputImpl encoderOut = getEncoderOut(session,
nextFilter, writeRequest);
try {
encoder.encode(session, message, encoderOut);
// Here, the encoded message is sent.
encoderOut.flush();
// Here an empty message is sent...
nextFilter.filterWrite(session, new WriteRequest(
new MessageByteBuffer(writeRequest.getMessage()),
writeRequest.getFuture(),
writeRequest.getDestination()));
In trunk, the code is slightly different, my the workflow is the same :
try {
encoder.encode(session, message, encoderOut);
encoderOut.flushWithoutFuture();
nextFilter.filterWrite(session, new MessageWriteRequest(
writeRequest));
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.
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 ?
Thanks and excuse my ignorance, I really didn't had a lot of time to
check the code ...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
