Hi Emmanuel,

Comments inline...

Emmanuel Lecharny wrote:
> 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.

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.

> 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.

HTH,
-- 
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to