That is great. I look forward to using the new filter as we have been having a lot more OOM problems on our clients under load testing (although that is as much a fault of the test app).
On 03/05/07, Vinod Panicker <[EMAIL PROTECTED]> wrote:
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 >
-- Martin Ritchie
