Pavel Zdenek wrote:
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...
It depends if you have an executor in your chain. If you don't, then
every message processing for a session will be processed by a single
thread : the one associated with the IoProcessor (as the IoProcessor
holds the selctor, it makes sense).
Now, if you have an executor, you may have a message processed by
different threads, as the exector acts as a demultiplexer : it picks a
thread in the pool and ask it to process the message. If your executor
is used in both side (you can perfectly ask the executor not to be used
when writing messages), then another thread will e used to write the
message (not sure what will be the impact though ...)
Is there any document describing the threading model of MINA? I
remember seeing some comprehensive picture about Netty, long time
ago...
Time's flying ... There are a few slides available, not sure if they are
accurate.
At some point, we should write some samples to demonstrate the different
use cases.
Thanks a lot,
Pavel Z.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
