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:04:56 GMT
David is correct, but maybe I can clarify. Even if the client-side is
completely done with the oneway request, the server may not have come
anywhere near completing the request. As such, the server side socket stays
open until the server has completed the request all the way.

In the particular case of oneway methods, you could conceivably close the
socket as soon as the request is fully read into the server's memory. If
this were a simple change and you submitted a patch for it, I would
entertain it.

However, I think a better solution would be to use one of the Thrift servers
like TNonblockingServer that support connection limiting. This way, they
will only open as many sockets as you allow it to before accepting new
clients.

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

> I'm sorry to post once more again,
> The connection is apparently useless, and keeping it open causes "too many
> open files" eventually.
>
> On Thu, Feb 11, 2010 at 7:46 PM, Utku Can Topçu <utku@topcu.gen.tr> 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