That's also an option, but you will have to send heartbeat message very often because memory can fill up very fast.
Steve Johns wrote: > 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/ >> >> >> >> -- 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
