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
