mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] IoHandler, to be shot ?
Date Sun, 10 Oct 2010 16:18:37 GMT
  On 10/10/10 10:19 AM, Julien Vermillard wrote:
> Hi,
> Got a bit of time today and I'm back messing with MINA 3.0 code.
> I'm actually looking at IoHandler.
> I know it's a big API break, but I don't get why we have filters&
> IoHandler.For me IoHandler is just a end of chain filter.
> I propose to remove it.
> Cheers,
After having refreshed my memory, here are some thoughts :

- We have a TailFilter, which is just some glue between the chain and 
the Handler. it however does a few useful things :
  * sessionOpened(), sessionIdle() just transfer the control to the 
  * messageSent() just extract the message from the WriteRequest object. 
I question this method though, as the Handler should be able to get it 
from the WriteRequest itself, and because the other information 
contained into the WriteReqest object might be useful for the IoHandler
  * filterWrite(), filterClose() are a bit strange, as they call the 
nextFilter, which obviously does not exist.
  * sessionCreated() update the ConnectFuture attribute, so the session 
can be informed that it has been created
  * sessionClosed() calls the IoHandler, then clean the 
WriteRequestQueue, the session AttributeMap, the session chain and the 
readFutures. It's a bit doubtful that all this logic should be processed 
here, when it's more likely to be done before we enter the chain for the 
WriteRequestQueue and the readFutures, and after we come back from the 
handler for the attributes and the session chain. In fact, the deletion 
of the session will already remove all those elements.
  * exceptionCaught() method just update the FailFutures, whch could be 
done elsewhere too
  * messageReceived() updates the statistics and add the message into 
the readFutures, I don't have any idea why... (Still hav to figure out this)

Otherwise, the IoFilter interface is way bigger than the IoHandler one, 
as it includes all the methods used to manipulate the chain itself 
(addition, removal of filters...), somethng we don't need in the IoHandler.

Bottom line, if we remove the IoHandler, that will have some huge impact 
on the client side and on the filter side. OTOH, I really think we 
should review the IoFilter interface. We already discussed about the 
presence of the NextFilter paraeter in all the IoFilter methods, and 
this may also have an impact on the refactoring.

I would keep the IoHandler in the picture atm, for convenience, but I'm 
not sure we could not remove it soon, if we also redesign the full 
filter interface.

Emmanuel L├ęcharny

View raw message