thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Utku Can Topçu <u...@topcu.gen.tr>
Subject Re: Java Server Does Not Close Sockets immediately for oneway methods
Date Thu, 11 Feb 2010 18:05:13 GMT
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