Hmmpphhhh....
I have traced the calls when a session.write( <blah> ) is done.
It's all a kind of a hack.
In order to be able to send the messageSent() event, the protocolFilter
will call the nextFilter.filterWrite() method twice :
public void filterWrite(NextFilter nextFilter, IoSession session,
WriteRequest writeRequest) throws Exception {
Object message = writeRequest.getMessage();
...
// Write all the encoded messages now
while (!bufferQueue.isEmpty()) {
Object encodedMessage = bufferQueue.poll();
// Flush only when the buffer has remaining.
if (!(encodedMessage instanceof IoBuffer) ||
((IoBuffer) encodedMessage).hasRemaining()) {
SocketAddress destination =
writeRequest.getDestination();
WriteRequest encodedWriteRequest = new
EncodedWriteRequest(encodedMessage, null, destination);
nextFilter.filterWrite(session, encodedWriteRequest);
}
}
// Call the next filter
nextFilter.filterWrite(session, new
MessageWriteRequest(writeRequest));
The first call we go down the chain with an IoBuffer containing the
encoded message, the second call will use th e original message wrapped
in a specific MessageWriteRequest instance, which will always return an
empty IoBuffer when a getMessage() is called on it :
private static class MessageWriteRequest extends WriteRequestWrapper {
@Override
public Object getMessage() {
return EMPTY_BUFFER;
}
It goes down the chain to the HeadFilter where it gets stacked to be
written. But as it's an empty buffer, the flush() method will do nothing
but initiate a call to messageSent() which will pop up to the handler.
Actually, the messageSent() event will be issued twice, once with the
encoded message, and it will be swallowed silently by the
ProtocolCodecFilter :
public void messageSent(NextFilter nextFilter, IoSession session,
WriteRequest writeRequest) throws Exception {
if (writeRequest instanceof EncodedWriteRequest) {
return;
and a second time with the EMPTY buffer, which will bubble up to the
IoHandler, with the original message.
This is overly complex, and leads to spurious CPU being consumed. It
would be way smarter to encapsulate the original message in a
WriteRequest instance, go though the filters with that, up to the
encoder filter to feed a IoBuffer into this WriteRequest, which will be
written to the remote peer, and when done, a messageSent event will be
generated using the original message. If th eoriginal message is a
IoBuffer that does not require encoding, then it's enough to keep the
encoded message to null, up to the HeadFilter to find out that the
original was never transformed so that it can write it, and let the
IoProcessor generate a messageSent event after having flipped the
original message to rest it back to its original position and limit. No
reset, no mark, just a flip.
