Hi! AFAIK, the messageSent is the only way to react when a message is finally sent. filterWrite is already called *before* the message is passed to the cable. How can I implement timings, like request/response timeout filters? Using filterWrite for this could be problematic for decoding will consume some undefined/-able amount of the time(out). If there's another way to do this, let me know.
regards Steve > Emmanuel Lecharny [mailto:[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 >
