Sorry for not responding to this important thread actively recently.
On 4/30/07, Vinod Panicker <[EMAIL PROTECTED]> wrote:
On 4/29/07, Paul Chen <[EMAIL PROTECTED]> wrote: > After curbing the read rate (one quota per acceptor) at a conservative rate, > the write problem is automatically gone. Not really. The read quota can be applied per acceptor, but the server might have connectors that could be writing to slower clients, leading to another OOM.
True.
> This is not an approach that leads to optimal performance, but just a way > to protect our Mina-based server not run into OOM. Using throttling is a solution that leads to better performance because the server can provide a good quality of service. Without throttling, all clients get affected because the server is not able to manage the incoming and outgoing data, resulting in an OOM.
To wrap up the discussion so far: 1) MINA must provide a solution that takes care of OOM situation caused by too fast or slow client/server. 2) Throttling only read opetions won't solve all OOM cases (i.e. slow client), we need to provide a filter (or filter builder) that can throttle write operations, too. Here's what I thought so far: 1) We need to merge ReadThrottleFilterBuilder and WriteBufferLimitFilterBuffer (DIRMINA-302) to provide a one-stop solution for the OOM issue. 1-a) We don't want to break backward compatiblity, so this solution will appear in 2.0.0-M1-SNAPSHOT. 1-b) We could provide WriteBufferLimitFilterBuilder in the next release of branches/1.0 and branches/1.1. This is a feature addition strictly speaking, so we might need to create a new branch (i.e. 1.2 and 1.3? :). 2) Using a filter mechanism rather than providing a new parameter is more elegant, and there's nothing to learn. (I agree.) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
