As always, patch are welcome ;) Julien
Le Tue, 17 Nov 2009 18:18:45 +0100, Mathieu Sacrispeyre <[email protected]> a écrit : > > > Ok I guess I do not need to give you a sample anymore. > Please tell us when the correction is available in the trunk. > > Emmanuel Lecharny wrote: > > Pavel Zdenek wrote: > >> 2009/11/17, Emmanuel Lecharny <[email protected]>: > >> > >>> <snip/> > >>>> - 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. > >> > > Damnit ! That's my fault. I didn't realized back then that moving > > those elements to static as such a side effect. I must have been > > totally drunk... > >> 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? > >> > > Well, AFAIR, it was probably an idiotic attempt to optimize the > > code. > > > > Btw, as I said in my response to Pavel, don't mail privately to > > committers, it kills the communication. As everyone can see, one's > > problem can ring a bell for another one user, and at the end, a > > solutiuon to a problem can be found. > >> 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. > >> > > When I wrote 'courageous', I meant that the initial code wasn't > > totally intended to allow codecs to be chained. At least in 2.0. > > The ProtocolCodecFilter messageReceived() code starts with : > > > > public void messageReceived(NextFilter nextFilter, IoSession > > session, Object message) throws Exception { > > LOGGER.debug( "Processing a MESSAGE_RECEIVED for session > > {}", session.getId() ); > > if (!(message instanceof IoBuffer)) { > > nextFilter.messageReceived(session, message); > > return; > > } > > ... > > > > It's obvious that if the next filter is a codec, then you must pass > > a IoBuffer. This is absolutely not what we want to pass, as the > > first codec is usually transforming a IoBuffer to some other data > > structure, and the second codec is supposed to deal with this very > > data structure. > > > > This is the reason I said 'courageous' : you have to know about > > this atrocious hack in order to get the second codec to work, that > > means you also have to store the intermediate result in the > > session. No fun ... > > > > Unless I'm totally wrong, of course ! > >> What is the architecturally correct and acceptably less courageous > >> advice on implementing such protocol? > >> > > From a pragmatic POV, when using MINA 2.0, try to get all the codec > > in one simple filter. That could lead to some complex stateful > > decoder, but at least, you have the hand on the code. > > > > Hope that MINA 3.0 will be better ! > > > >
signature.asc
Description: PGP signature
