Maybe one approach would be to categorize the ways in which people reach OOM conditions. Do these conditions happen only when the input and/or output queues get really large, or are there other reasons. Once we can start to categorize the OOM conditions that users are experiencing, we can properly move forward with solutions.
Basically what I mean is, if the OOM happens when queues fill up, then throttle filters would be best. If the OOM happen for other reasons, people could look at other areas of MINA. Just not sure there is one solution that will fix all the problems. ...just my 2 cents. -- ..Cheers Mark On 4/25/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote:
Hey Marcin, I see what you mean. I'm really fine with either option as long as MINA handles the OOM problem. As I posted a month or so ago the throttling per connection is not enough. We (Openfire and probably others) also need a global throttling. Thanks, -- Gato -----Original Message----- From: Marcin Waldowski [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 1:36 PM To: [email protected] Subject: Re: Permanent solution for OOM errors Hej Gaston, Gaston Dombiak wrote: > Hey Marcin, > > I'm curious to hear from you why do you think so? I absolutely agree > that MINA has to provide easy ways to handle OOM problems due to heavy > incoming or outgoing traffic. > > This is by far the more common problem people are reporting with > Openfire now that we moved to MINA (when under heavy load). > Hmm, my first thought was that it introduce the complexity of configuration like ThreadModel. But probably I'm wrong. I agree definitely that MINA need solution for OOM, but it could be also ReadThrottleFilterBuilder and WriteThrottleFilter. They are easy way to handle OOM and (what is important) users are aware that they use it. But I'm not agains integrate it as default to Acceptor/Connector, really :) Meybe I even souldn't post my doubts to this subject because I haven't contributed to MINA so far... Regards, Marcin
