2009/11/23, Emmanuel Lecharny <[email protected]>: > Pavel Zdenek wrote: >> 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? >> > The way it works is that each 'message' is enqueued until it's sent. > Then a MessageSent event is generated. Sadly, we don't associate a umber > with each message, so it's difficult to correlate a MessageSent event > with a given message, except that AFAIR, the IoBuffer is present in the > messageSent event. > > If so, you may be able to compare the message content with what you know > to be the last message sent (you can store it in the session for > instance). This is from the top of my head...
Fortunately my protocol is strictly synchronous request/response, so the message matching will be much easier. Safety question: may it happen, that the session handling (which writes a response object into the session) will be the same thread as the one which initiates messageSent? From my observation, this is not the case, but i prefer asking first and shoot a code later... Is there any document describing the threading model of MINA? I remember seeing some comprehensive picture about Netty, long time ago... Thanks a lot, Pavel Z.
