Or you can use heartbeat at client side if it didn't receive heartbeat for a while. Right?
On Wed, Apr 9, 2008 at 7:50 PM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote: > Hi Gato, > > Glad to see you again in the mailing list. I hope OpenFire team is > happy with MINA. > > Throttling too fast read can be controller by using > o.a.m.f.executor.IoEventQueueHandler. There's already a simple > implementation called 'IoEventQueueThrottle' that throttles an executor > in a per-filter manner. Of course, you can write your own event queue > handle to control the traffic of an individual session to drop too fast > or malicious client. > > Throttling too fast write is a very different problem comparing to the > 'read' problem because the implementor have full control over how fast > his or her implementation will write. You can always check the > IoSession.scheduledWriteBytes/Messages property and drop or slow down > the connection as you want. Plus, you can set writeTimeout for your > session to smaller value then you will be notified with > WriteTimeoutException. > > However, I didn't find more elegant way to do the writer-side throttling > yet. Any idea is welcome! > > HTH, > > Gaston Dombiak 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/ > > > > -- > Trustin Lee - Principal Software Engineer, JBoss, Red Hat > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > > > >
