Trustin Lee wrote:
On 11/8/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
On 11/8/07, Luis Neves <[EMAIL PROTECTED]> wrote:
Hello,
Trustin Lee wrote:
Hi community,
Recently, I've been working on traffic throttling filters, which
prevents unwanted OutOfMemoryError due to high bandwidth asynchronous
operations, and I want to get as much feed back as possible from you.
Looking at this again...
I'm having issues with multiple clients. It seems that using the
ReadThrottleFilter "attached" to a SocketAcceptor makes it impossible for the
server to process messages from more that one client (when all the clients are
"blasting" the server).
What I'm seeing is that a blocked client doesn't resume message production
(ever). I will try to track the reason for this. Looking at the code it seems
that it would make sense to pass a reference to the IoService, so that we could
call "session.resumeRead()" for all "getManagedSessions()"... but i could be way
off, what do you think?
I think it is the only solution to fix this bug and support
per-service and global read throttling, but it's really really
expensive. The filter will have to iterate a set of sessions for
every messageReceived event, which is an overkill. We probably might
need to drop the current per-service and global read throttling and
find an alternative way. WDYT?
Hmm.. however, read suspension seems to work pretty well. We might be
able to reduce the overhead by reducing the execution frequency of
resume check code.
Trustin
There is a "timing" issue with the "resumeOhters()" function.
If a client is blocked and all others client sessions are closed the
resumeOthers won't be called and the client doesn't resume.
--
Luis Neves
