mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: PorotocolCodecFilter potential pbs and improvement
Date Fri, 05 Sep 2008 14:40:28 GMT

>> 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 
> 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

View raw message