To make the statement clear, I should add that the Sockets are closed eventually after the oneway method completes. What I think the correct behavior should be is the case that, first closing the sockets then processing the request.
Best Regards, Utku On Thu, Feb 11, 2010 at 7:23 PM, Utku Can Topçu <[email protected]> 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 >
