Is it possible to use session.getReadMessages() session.getWriteMessages() when you try to read and write. If the number is huge, just close the session?
On Tue, Apr 8, 2008 at 12:30 AM, Gaston Dombiak <[EMAIL PROTECTED]> wrote: > Hey Trustin, > > I'm not using 2.0 so I'm not familiarized with the 2.0 code. From our > experience, the most common OOM problems we found are 1) server is receiving > data faster that it can process and 2) client connection is down or slow to > read so outgoing queue gets bigger and bigger. > > For #1 the throttling should try to keep the increasing queue out of the > Java memory so at least it's not Java the one that will run OOM. The TCP > stack should eventually read slower so it should slow down the client thus > avoiding the crack down of the server. > > For #2 I think the trick is harder since its not about not processing data > from the client. That means that any other incoming socket may place data to > be sent to a slow or faulty client. For this type of problem we rely on 2 > workarounds: 1) Close idle users (in our case listen only for incoming > traffic) and 2) Close/discard connections whose queue is "too" big. I know > that these are not perfect but they are enough for us. > > Having said all that, how will 2.0 handle those 2 OOM scenarios? > > Thanks, > > -- Gato > > -----Original Message----- > From: "이희승 (Trustin Lee) [mailto:[EMAIL PROTECTED] > Sent: Monday, April 07, 2008 7:06 AM > To: [email protected] > Subject: Re: Dropping traffic throttling from 2.0 > > Hi Niklas, > > I forgot to your reply and please forgive my another too late reply. :) > > Yeah, I am suggesting to remove ReadThrottleFilter, WriteThrottleFilter > and TrafficShapingFilter. Consequently all classes under > org.apache.mina.filter.traffic should be removed. > > Of course, MINA provides an alternative way to prevent OOM. If you take > a look into org.apache.mina.filter.executor package, you will find > IoEventQueueThrottle which implements IoEventQueueHandler. You can > prevent OOM by specifying proper IoEventQueueThrottle when you construct > Ordered/UnorderedThreadPoolExecutor. > > Let me wait for another 3 days and move the > org.apache.mina.filter.traffic to sandbox until someone makes it work > correctly. For now, it's full of inefficiency and bugs. > > Thanks, > > Niklas Gustavsson wrote: > > Just so that I fully understand the proposal. The stuff you want to > > remove are the ReadThrottleFilter and WriteThrottleFilter and > > associated classes? Would you like them removed for 2.0 due to them > > not being sufficiently mature and then bring them back later as they > > get better. Or do you want them removed for good? > > > > Given that there has been some questions here on this topic (people > > getting OOM exceptions), some type of recommendation/solution should > > be provided, right? Documentation that explains how to do it in the OS > > IP stack would be fine for me. > > > > Or I might be misunderstanding your proposal completly :-) > > > > /niklas > > > > On Mon, Mar 17, 2008 at 11:31 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> > wrote: > >> Hi, > >> > >> I'd like to propose to drop the current traffic throttling filters > from > >> 2.0. The reasoning behind this proposal is: > >> > >> 1) Traffic throttling is very difficult to implement - our > implementation > >> seems to be buggy. > >> 2) Most operating systems already provide QoS stack. > >> > >> Of course, this doesn't mean we have to drop existing overload > prevention > >> mechanism included in OrderedThreadPoolExecutor and > >> UnorderedThreadPoolExecutor. > >> > >> WDYT? > >> > >> -- > >> Trustin Lee - Principal Software Engineer, JBoss, Red Hat > >> -- > >> what we call human nature is actually human habit > >> -- > >> http://gleamynode.net/ > >> > > -- > Trustin Lee - Principal Software Engineer, JBoss, Red Hat > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > >
