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 <[email protected]> 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 <[email protected]> >> 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
