mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Johns" <steven.mark.jo...@gmail.com>
Subject Re: Dropping traffic throttling from 2.0
Date Sat, 12 Apr 2008 01:17:06 GMT
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) <trustin@gmail.com>
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:trustin@gmail.com]
> > 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) <trustin@gmail.com>
> 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/
>
>
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message