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: dev@mina.apache.org > 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/
signature.asc
Description: OpenPGP digital signature
