+1 On Tue, Nov 11, 2008 at 11:59 AM, Edouard De Oliveira <[EMAIL PROTECTED]>wrote:
> 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]> > À : [email protected] > 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 > > > > > > > > > > >
