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 17:46:49 GMT
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