Emmanuel Lecharny napsal(a):
Pavel Zdeněk wrote:
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
Ok, so I checked the code. It hasn't changed since the first version
of MINA so it's not a regression. Funny enough, I have posted the same
question one year ago :
http://mail-archives.apache.org/mod_mbox/mina-dev/200804.mbox/%[email protected]%3e
So basically, as dumb as it sounds, the empty message is written
*just* to increment a counter of sent messages. There is obviously a
better way to do that, but I didn't had time yet to find a solution.
Hope it helps...
So, if i got a filter in the chain which actually works with the data
(adds a message-independent header) and not just the transport/protocol
metadata (like most of the example filters), it must explicitly skip
those zero-size messages? So far the logic was "add a header to anything
what falls down to you" - so the zero message became nonzero. Secondly,
does it mean that i a) must forward this empty message if i want to get
a messageSent event later b) the message is NOT physically sent out to
the transport? I admit that adding a header in the filter may look
strange to you, but it is just a legacy wrapper for backward
compatibility and have nothing to do with the data itself, so a filter
seemed to be a nice separative solution.
Cheers, PZ.
