I've already done that. It's being tested right now. We'll be contributing that as soon as we are happy about the performance under high load.
On 5/2/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
On 30/04/07, Paul Chen <[EMAIL PROTECTED]> wrote: > I'm refining that to make it more presentable and generic, will publish that > in 1 week or 2. > > On 4/30/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote: > > > > Hey Paul, > > > > That is exactly what I was planning to implement for our case. Can you > > send me your modified version? I would like to include it in Openfire. > > > > Thanks, > > > > -- Gato > > > > -----Original Message----- > > From: Paul Chen [mailto:[EMAIL PROTECTED] > > Sent: Monday, April 30, 2007 1:07 PM > > To: [email protected] > > Subject: Re: Permanent solution for OOM errors > > > > I actually *tweaked* the read throttle to take the output Queue size > > into account to avoid the slow write syndrome. Maybe I should call > > it traffic control throttle instead. > > > > Cheers > > > > On 4/29/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. Hi, I've been watching this thread grow but not had time to contribute (Sorry about that). The Qpid project is hoping to move the latest released version of mina and so I would be happy to take another look at the WriteThrottleFilter (on DIRMINA-302) to see how it can be tidied up. Specifically the filter currently limits by number of requests whereas the number of bytes on the queue would be far better solution. -- Martin Ritchie
