That would imply some kind of synchornization on the session, I guess.
Something we can add.
In fact, that one is a guarantee we already have. At least when using
an OrderedThreadPoolExecutor (or no executorfilter at all)
see
http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/executor/ExecutorFilter.html
Maybe it should be true in all case. Is there any advantage of having
not-synchronized sessions ? (except the speedup we can have).
or another idea would be to forbid an incoming request on a session
which is currently being processed.
I don't have a clear idea about it yet, so consider my proposal much
more as a brainstorming.
But why synchronize on the factory instead of on the session ?
Well, because it would imply we synchronize all the other part of the
server where we access the session, a little bit overkilling, IMHO.
Sorry, I don't understand what you are saying. Why would we have to
change other parts of the code ?
Synchronizing on the factory (which is shared by all sessions) creates
a portential contention problem while IMO it's enough to synchronize
on the session : we just have to ensure that we don't call
factory.getDecoder(session) twice for one session.
Damn, you are right !
But ok, this discussion is not really relevant because it's probably
better to move this initialization to sessionCreated.
Yep, you are right too : it's irrelevant, and the proposal I made about
using the createSession() event was just about removing this painfull
synchronization.
Don't know whether it's documented somewhere, but looking at
ExecutorFilter code, I think it's safe to say that sessionCreated will
always be called BEFORE messageReceived. (That's another promise to
add to the list of framework guarantees, I guess.)
Yeah, I guess that it's the case. It does not makes sense to me that
some session may receive a message _before_ it has been created. *But* I
have to double check that the session is moved to a state where it can
be uses _after_ the sessionCreated event is sent and processed.
So your proposal looks OK to me.
Fine. I will push the code then after having done the checks we have
talked about.
Thanks for the review and insightfull comments !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
