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 Tue, 08 Apr 2008 06:48:35 GMT
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 <gato@jivesoftware.com>
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/
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message