Trustin Lee wrote:
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?
Yeah... it seems hideously expensive.
I think that I don't need that kind of control (session, service, global), my
only use for the ReadThrottleFilter is to make the JVM not crash with OOM errors :-)
Although I understand the arguments for fine grained control, I can live happily
with only a global limit (shared for all the sessions)... so to solve this
problem I would probably set the limit per session to something like:
min(512K, (globalBufferSize /number of sessions))
or something similar.
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.
That is also a possibility but I'm leaning to the simpler solution (limit only
for session), but you know you baby better than me.
--
Luis Neves
