> 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?
Yep. As I said, the internal logic is flawed, as it uses empty messages for internal manageme,nt, which is really a stupid idea. Now, you have the guarantee that after the codec (well, "after" means "when the encoder has proceced the response, so it's for a filter before the codec in the chain), an empty message is just irrelevant. So far the logic was "add a header to anything what falls down to > you" - so the zero message became nonzero. That's just fine if you do that before the encoder kicks in, as it's the encoder which generates the empty message. Secondly, does it mean that i a) > must forward this empty message if i want to get a messageSent event later Yes. > b) the message is NOT physically sent out to the transport? Yes. 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. Well, I don't know anything about your protocol, so I can't say if it's smart or not :) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
