2009/11/17, Emmanuel Lecharny <[email protected]>: > Mathieu Sacrispeyre wrote: >> Hello, >> > Hi, >> I have a project which is working fine with mina 2.00 M5 and serial >> transportation. >> I tried to update to rc1 but it do not work anymore. >> >> There is an handler that adds a protocol codec filter to the 2 placed by >> its superclass in the filterchain of the session. >> Something like this : >> connector.getFilterChain().addLast(PROTOCOL_NAME_TRANSPORT, >> new ProtocolCodecFilter(new >> TransportProtocolCodecFactory())); >> connector.getFilterChain().addLast(PROTOCOL_NAME_BUSINESS, >> new ProtocolCodecFilter(new >> BusinessProtocolCodecFactory())); >> >> Then in the child handler : >> connector.getFilterChain().addBefore(ADlMinaHandler.PROTOCOL_NAME_HIGH, >> PROTOCOL_NAME_INTERMEDIATE, >> intermediateProtocolCodecFilter); >> >> With the rc1 version when calling session.write, it ends with a >> stackoverflow iterating on these lines : >> at >> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:508) >> at >> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$7(DefaultIoFilterChain.java:502) >> at >> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:807) >> at >> org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolEncoderOutputImpl.flushWithoutFuture(ProtocolCodecFilter.java:435) >> at >> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:301) >> >> It seems that it is looping on the business and intermediate protocol >> filters without any call to the transport one : the content of the >> resulting filterchain or the way entries are iterated may have changed >> between the 2 versions...? >> >> Before having a deeper look at the issue, I wanted to know/confirm : >> - if this is a known issue (haven't seen something about that on this >> mailing list...) >> > No, AFAICT >> - if the use of mina described here is correct >> > Enqueueing two codecs is a bit courageous... >
Nice, i was just going to write my own post on the matter of enqueueing two codecs, which as well stopped working for me with RC1. I did have found a reason why it stopped working, and it matches with the "courage" label. On revision 790000 of 30 June, ProtocolCodecFilter has been actually modified to PROHIBIT multiple instances in the chain. The private AttributeKeys had been changed to static. Which means that there exists only one encoder and decoder instance per whole chain, and that is the one for which the initCodec has been called as the last one. Unfortunately the rewrite of existing instances is completely silent. I have even contacted the commiter directly some weeks ago, but he didn't respond. There surely must be a deeper reason, an architectural decision, which have induced this change? About my reasons for being courageous: i do a server which accepts traffic from microcontroller based GPRS stations with very limited memory resources. Because of that, messages are packetized to about 0.5kB which is the limit of what the client can prepare at once. Each packet has own header with length and sequence number. For that i obviously need a CumulativeProtocolDecoder. After receiving all packets, server does join them, checks CRC and THEN i need the actual DemuxingProtocolCodecFactory to handle the big thing. There is about 20 different message types, so i really would like to use what is already done, instead of reinventing my own demuxing wheel somehow inside the SessionHandler. What is the architecturally correct and acceptably less courageous advice on implementing such protocol? Thanks, Pavel Z.
