Hello everybody,
i am having serious problems with my application based on
DemuxingProtocolCodecFactory. By progressive stripping of the code to
get minimal presentable part, i had ended up recognizing that
example.sumup (which is the only example based on DemuxingP.C.F.)
produces the same misbehavior.
I have taken vanilla sumup.codec example, making two following
modifications:
- changing the timeouts on read/write to ease debugging
- in Server, adding one more LoggingFilter BEFORE codec, making it first
filter in the chain
On executing "Client 1 2" the log is saying
CREATED
CREATED
OPENED
OPENED
SENT: HeapBuffer[pos=0 lim=10 cap=16: 00 01 00 00 00 00 00 00 00 01]
SENT: HeapBuffer[pos=0 lim=0 cap=0: empty]
SENT: 0:ADD(1)
SENT: HeapBuffer[pos=0 lim=10 cap=16: 00 01 00 00 00 01 00 00 00 02]
SENT: HeapBuffer[pos=0 lim=0 cap=0: empty]
SENT: 1:ADD(2)
My understanding is, that IoHandler produces only one message as
expected, but there are actually two messages written by codec. The
second one is always of zero size, but the action is taken anyway
(filterWrite is executed).
I have tracked the dual chain execution to method
ProtocolCodecFilter.filterWrite, where you first call
((ProtocolEncoderOutputImpl)encoderOut).flushWithoutFuture();
and then immediately
nextFilter.filterWrite(session, new MessageWriteRequest(writeRequest));
where only the encoderOut holds the required encoded content (16 bytes)
and and the second call only shuffles a bogus request with zero data.
This behavior is unusable for me, because i have used the filter chain
facility for somewhat elaborate purposes and all that machinery is fired
twice for every outgoing message. Yes i could easily write very simple
filter throwing away any write request with zero data, but this is so
strangely serious misbehavior that i am asking someone to reproduce
first or tell me my sins.
Cheers,
Pavel Zdenek
