You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Niklas Therning <ni...@trillian.se> on 2005/11/02 21:43:30 UTC
[mina] Problem with BlacklistFilter
I think the BlacklistFilter should implement all of the upstream
IoFilter callbacks, not just sessionCreated(), to prevent those events
to be propagated to the IoHandler. I have a situation where
messageReceived() is called in my IoHandler even if BlacklistFilter has
blocked the client. I guess it's because it takes some time for the
CloseRequest to be picked up by SocketIoProcessor.
If we don't want to call BlacklistFilter.isBlocked(IoSession) for every
upstream event we could instead add an attribute to the session in
BlacklistFilter.sessionCreated() which tells whether the connection is
blocked or not and use that attribute in all the other events.
WDYT?
/Niklas
Re: [mina] Problem with BlacklistFilter
Posted by Niklas Therning <ni...@trillian.se>.
Trustin Lee wrote:
> ...
>
> It would be nice if there are always consistency in what order the
> IoHandler callbacks are called. E.g. sessionCreated is always called
> first, then sessionOpened, then 0 or more messageReceived/messageSent
> followed by sessionClosed. If only sessionCreated is blocked,
> sessionOpened could be called first which could lead to strange
> bugs if
> the Mina user uses sessionCreated to allocate resources etc.
>
>
> There's already consistency. sessionCreated is invoked first, and
> then sessionOpened, and messageReceived/Sent, sessionClosed. Please
> let me know if any exceptional event order is found.
Great! I only meant that if sessionCreated() is blocked in
BlacklistFilter and sessionOpened() isn't it could lead to
inconsistencies. But it seems to have been all taken care of now with
the new BlacklistFilter version. Thanks!
/Niklas
Re: [mina] Problem with BlacklistFilter
Posted by Trustin Lee <tr...@gmail.com>.
Hi Niklas,
Cheers,
Trustin
2005/11/8, Niklas Therning <ni...@trillian.se>:
>
> I'm afraid it's not enough to block sessionCreated() and
> messageReceived(). I think all IoFilter methods except init() and
> destroy(), filterWrite(), filterClose() and maybe exceptionCaught() will
> have to be intercepted by BlacklistFilter and checked against the
> blacklist.
Thanks for your advice. It makes sense. I checked in the fix.
It would be nice if there are always consistency in what order the
> IoHandler callbacks are called. E.g. sessionCreated is always called
> first, then sessionOpened, then 0 or more messageReceived/messageSent
> followed by sessionClosed. If only sessionCreated is blocked,
> sessionOpened could be called first which could lead to strange bugs if
> the Mina user uses sessionCreated to allocate resources etc.
There's already consistency. sessionCreated is invoked first, and then
sessionOpened, and messageReceived/Sent, sessionClosed. Please let me know
if any exceptional event order is found.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] Problem with BlacklistFilter
Posted by Niklas Therning <ni...@trillian.se>.
Hi,
I'm afraid it's not enough to block sessionCreated() and
messageReceived(). I think all IoFilter methods except init() and
destroy(), filterWrite(), filterClose() and maybe exceptionCaught() will
have to be intercepted by BlacklistFilter and checked against the blacklist.
It would be nice if there are always consistency in what order the
IoHandler callbacks are called. E.g. sessionCreated is always called
first, then sessionOpened, then 0 or more messageReceived/messageSent
followed by sessionClosed. If only sessionCreated is blocked,
sessionOpened could be called first which could lead to strange bugs if
the Mina user uses sessionCreated to allocate resources etc.
/Niklas
Trustin Lee wrote:
> Ah I see. I'll fix that now.
>
> 2005/11/3, Niklas Therning <niklas@trillian.se
> <ma...@trillian.se>>:
>
> I think the BlacklistFilter should implement all of the upstream
> IoFilter callbacks, not just sessionCreated(), to prevent those events
> to be propagated to the IoHandler. I have a situation where
> messageReceived() is called in my IoHandler even if
> BlacklistFilter has
> blocked the client. I guess it's because it takes some time for the
> CloseRequest to be picked up by SocketIoProcessor.
>
> If we don't want to call BlacklistFilter.isBlocked(IoSession) for
> every
> upstream event we could instead add an attribute to the session in
> BlacklistFilter.sessionCreated() which tells whether the connection is
> blocked or not and use that attribute in all the other events.
>
> WDYT?
>
> /Niklas
>
>
>
>
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
--
Med vänlig hälsning
Niklas Therning
Software Architect
niklas@trillian.se
Mobil: +46 739 75 05 73
Trillian - Software Design at its best
www.trillian.se
Re: [mina] Problem with BlacklistFilter
Posted by Trustin Lee <tr...@gmail.com>.
Ah I see. I'll fix that now.
2005/11/3, Niklas Therning <ni...@trillian.se>:
>
> I think the BlacklistFilter should implement all of the upstream
> IoFilter callbacks, not just sessionCreated(), to prevent those events
> to be propagated to the IoHandler. I have a situation where
> messageReceived() is called in my IoHandler even if BlacklistFilter has
> blocked the client. I guess it's because it takes some time for the
> CloseRequest to be picked up by SocketIoProcessor.
>
> If we don't want to call BlacklistFilter.isBlocked(IoSession) for every
> upstream event we could instead add an attribute to the session in
> BlacklistFilter.sessionCreated() which tells whether the connection is
> blocked or not and use that attribute in all the other events.
>
> WDYT?
>
> /Niklas
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/