thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Java Server Does Not Close Sockets immediately for oneway methods
Date Thu, 11 Feb 2010 19:15:16 GMT
It sounds like you need an extra queuing layer.  The thrift call can insert
the request into the queue (and thereby close the socket).  It should be
possible to insert 500 transactions per second into a large queue with no
difficulty at all.

The real problem here is not the late close.  It is the fact that you can't
handle your peak volume without a huge backlog.  If you design a layer that
can absorb the backlog, then the problem will go away.  You still have the
problem that if your peak is 4x higher than the rate that you can process,
then you are probably getting close to the situation where you can't keep up
with your average load either.

On Thu, Feb 11, 2010 at 11:10 AM, Utku Can Topçu <utku@topcu.gen.tr> wrote:

> Ted,
>
> I sure agree with you, however having 500*x more threads for handling the
> concurrency, will eventually set the processing time for one request from 4
> seconds to 4*x seconds.
> At the end of the day the open connection count will be the same ;)
>
> Best,
> Utku
>
> On Thu, Feb 11, 2010 at 9:06 PM, Ted Dunning <ted.dunning@gmail.com>
> wrote:
>
> > This is the key phrase that I was looking at.  If you only allow 500x
> > concurrency and you are getting 500 transactions per second, then you are
> > going to back up pretty seriously.
> >
> > On Thu, Feb 11, 2010 at 10:58 AM, Utku Can Topçu <utku@topcu.gen.tr>
> > wrote:
> >
> > > > > time. Say each request needs 4 seconds to complete in 500
> > concurrency.
> >
> >
> >
> >
> > --
> > Ted Dunning, CTO
> > DeepDyve
> >
>



-- 
Ted Dunning, CTO
DeepDyve

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message