Hallo, Well I don't think the way it is stored is irrelevant.
I try to explain again. I have a filter chain like this: 1.) TCP2.) ProtocolCodecFilter with ProtocolCodecA ( Transforming IoBuffers to MessageA ) 3.) SomeFilter ( Doing stuff and extracting IoBuffers from some types of MessageA) 4.) ProtocolCodecFilter with ProtocolCodecB (Transforming IoBuffers to MessageB )
5.) IoHandlerNow since the ProtocolCodecFilter from 2 and 4 access the same IoSession attributes, the use the same output object of the ProtocolCodecFilter (in my case, the second added, the one from 4). Now messages that are decoded in step 2 end up in the output of step 4.
I could reproduce and fix it by using "getClass()" for the AttributeKey instead of using ProtocolCodecFilter.class _and_ by making a dummy-subclass from ProtocolCodecFilter in order to have a different class. This is not a good solution, but it worked just for testing.
I hope this explains it a bit better. On 11/23/2012 03:20 PM, Emmanuel Lécharny wrote:
Le 11/23/12 12:22 PM, Jens Reimann a écrit :Hello, Mina (seen with 2.0.4 and retested with 2.0.7) seems to have a problem when multiple, different ProtocolCodecFilters are added to a filter chain. While the CumulativeProtocolDecoder class uses "getClass()" for creating the AttributeKey of its buffer ( -- BUFFER = new AttributeKey(getClass(), "buffer") -- ) the ProtocolCodecFilter itself uses "ProtocolCodecFilter.class" ( -- new AttributeKey(ProtocolCodecFilter.class, "encoder") -- ). In my scenario this seems to cause some (not all) messages to walk the wrong chain of filters, actually skipping the second ProtocolCodecFilter in the chain.Can you be a bit more explicit ? We are storing two differents attributes (one is the 'buffer', the other one is the 'encoder'), and the way we store them in the session is irrelevant. I suspect there is something else that cause your decoders to work in a way you don't expect.I am not sure what would the actual fix for that, but I would expect that it is possible to add multiple, different ProtocolCodecFilters to the same filter chain.The problem is that once you have decoded a bytes buffer, you now have a message. If the next decoder is expecting another bytes buffer, then it won't be happy. Or your second flter will have to decode a message, not an IoBuffer. Otherwise, you may want to decode the received IoBuffer using different decoder, but that means you should be able to detect which decoder to call. You have to code that. Unless I missed something...
smime.p7s
Description: S/MIME Cryptographic Signature
