Greetings fellow min(a)ers! I understand the controversy over messageSent, because the "feature" of firing twice per each actual object being encoded is annoying me as well. Anyway, i do need such sort of event information in my current pet project, something has to happen in the persistent layer after the message delivery is confirmed. Unfortunately, the most recommended hack solution with waiting on WriteFuture is neither applicable, because i do physically send out a multiple IoBuffers for each abstract message written. I need to get the messageSent on the last one, not the first one (as it happens now). I am thinking about setting up a wait condition after session.write and signalling it from the correct messageSent. But i am too unfamiliar with the threading model of Mina, to say whether it's a good idea. Somebody with better understanding say?
Thanks, Pavel Z. 2009/11/17, Mathieu Sacrispeyre <[email protected]>: > > > 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 ! >> >> >
