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 -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
