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
