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