lol Emm did you pay Rajeshwari just to support your proposal ? DIRMINA-634 should also be resolved by removing messageSent event which seems to be an unnecessary event that makes code even more cloudy.
so +1 Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php ________________________________ De : Mark Webb <[EMAIL PROTECTED]> À : dev@mina.apache.org Envoyé le : Mardi, 11 Novembre 2008, 4h18mn 53s Objet : Re: [MessageSent] let's remove it... spot on. +1. remove it. On Mon, Nov 10, 2008 at 7:11 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi guys, > > a few days ago, Julien suggested that we should remove this event. I never > used it, found it a bit cumbersome, but didn't had time to double check > what's doing. > > Let's go back to the mailing list... > > Back in july, I posted a mail where I questionned some 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())); > > There are two places in this code where the message is written : in the > encoderOut.flush() and in the filterWrote() call. > > Trustin replied saying : > > "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." > > There is an obvious way to be more efficient here : simply not sending this > messageSent event ! > > > But this is not a good enough reason to remove it. Let's dig another mail. > > https://issues.apache.org/jira/browse/DIRMINA-574 > > Steps to reproduce: > 1) Connection is closed at the socket level. > 2) A user writes a message. > 3) the message is encoded by a ProtocolCodecFilter. > 4) MINA notices the closed socket and fires a sessionClosed event. > 5) After the sessionClosed event is fired, IoFilterChain.clear() is called. > 6) MINA tries to write the user write request, but the session is closed > already - all write requests are discarded. > 7) Before MINA discards all write requests, MINA checks if the first item in > the queue is an empty buffer, which means a special separator which is > handled by ProtocolCodecFilter. > 8) If there's an empty buffer in the head of the queue, MINA fires a > messageSent event with the empty buffer in the hope that ProtocolCodecFilter > will catch it. > 9) However, the filter chain is empty and therefore IoHandler implementation > gets ClassCastException. > > > At step 8, we send a MessageSent event, which leads to an Exception. > Clearly, this is not good. Removing the MessageSent event will immediatly > solve this blocker issue. > > Last, not least, another mail states that : > > "Also, I'd like to make a plug for removing messageSent() callbacks and > having the end-user API rely on WriteFutures instead. It's a hassle to > write new filters when you have to worry about passing back the correct > object." > > Using WriteFuture will clearly be a better way to get the message as it has > been posted to the chain, instead to having to encode it back, as it's > currently done. > > Anyone disagree ? Anything I missed ? > > Thanks ! > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
