thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: Java Server Does Not Close Sockets immediately for oneway methods
Date Thu, 11 Feb 2010 18:18:22 GMT
Wow. With that kind of volume, I agree that you need an internal queuing
mechanism. Like I said - if you can produce a patch that would close sockets
more quickly, I'd consider it for inclusion.

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

> I think this would provide a significant benefit,
>
> Let me explain this briefly:
> In our production load, we have ~500 oneway requests per second in peek
> time. Say each request needs 4 seconds to complete in 500 concurrency.
> The client side successfully makes the request and closes it's connection.
> If we face a peek period more than 3-4 minutes the number open connections
> exceeds the number of connections allowed by the Operating System.
> 4*60*500 = 120000 socket connections in 4 minutes
> ((4*60)/4)*500 = 30000 requests processed in 4 minutes
> 120000 - 30000 = 90000 open connections afer 4 minutes of peek time
>
> That's a quite useless connection overload for async. request that won't
> care about the result of the execution.
>
> Best Regards,
> Utku
>
> On Thu, Feb 11, 2010 at 7:50 PM, David Reiss <dreiss@facebook.com> wrote:
>
> > It is too complicated to interrupt the thread in the middle of executing
> > the method to close the socket.  Plus, it doesn't provide any significant
> > benefit.
> >
> > Utku Can Topçu wrote:
> > > David, Thank you for the quick response
> > >
> > > Since the method is oneway as defined by Thrift IDL, should we still
> > insist
> > > on keeping the connection alive until the method finishes? Because of
> the
> > > "asynchronous call" paradigm, the assumption is the fact that the
> client
> > > would not care about the execution, result etc... of the related
> method.
> > >
> > > Best,
> > > Utku
> > >
> > >
> > > On Thu, Feb 11, 2010 at 7:42 PM, David Reiss <dreiss@facebook.com>
> > wrote:
> > >
> > >> That sounds right.  The client closes the socket, the server is still
> > >> processing the method, and it closes its side as soon as it finishes.
> > >>
> > >> Utku Can Topçu wrote:
> > >>> Hello David,
> > >>>
> > >>> I think there's a point missing. Even though the client (PHP in our
> > case)
> > >>> issues a "$transport->close()" the socket connection on the Server
> Side
> > >> is
> > >>> closed just after the execution of the oneway method.
> > >>>
> > >>> Best,
> > >>> Utku
> > >>>
> > >>> On Thu, Feb 11, 2010 at 7:28 PM, David Reiss <dreiss@facebook.com>
> > >> wrote:
> > >>>> We don't close the sockets because you are allowed to send multiple
> > >>>> requests
> > >>>> over the same connection.
> > >>>>
> > >>>> Requests received over the same connection are processed serially,
> in
> > >>>> order.
> > >>>>
> > >>>> Does that answer your question?
> > >>>>
> > >>>> Utku Can Topçu wrote:
> > >>>>> While experimenting with the oneway (asynchronous) service
calls to
> a
> > >>>> Java
> > >>>>> Service, we've faced a serious connection overload.
> > >>>>> Currently we're using TBufferedTransport together with
> > >> TThreadPoolServer
> > >>>> on
> > >>>>> the Server side.
> > >>>>> Diving deep into the Java Thrift Libraries, auto-generated
Java
> > classes
> > >>>> and
> > >>>>> debugging the code, we've seen that the oneway void methods
on the
> > Java
> > >>>>> Server side does not close the "TSocket"s that are related
to the
> > >> methods
> > >>>> in
> > >>>>> question.
> > >>>>>
> > >>>>> Is this a design decision? Should we treat this as a bug?
> > >>>>>
> > >>>>> Our current solution to this problem is employing a
> > ThreadPoolExecutor
> > >>>> for
> > >>>>> each oneway method, we immediately transform the asynchronous
> > requests
> > >>>> into
> > >>>>> Runnables and place them in the thread pool and return from
the
> > method.
> > >>>>>
> > >>>>> I think a similar approach should be implemented in the Thrift
Java
> > >>>>> libraries.
> > >>>>>
> > >>>>> What do you think on this issue?
> > >>>>>
> > >>>>> Best Regards,
> > >>>>> Utku
> >
>

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