I think this would provide a significant benefit, Let me explain this briefly: In our production load, we have ~500 oneway requests per second in peek time. Say each request needs 4 seconds to complete in 500 concurrency. The client side successfully makes the request and closes it's connection. If we face a peek period more than 3-4 minutes the number open connections exceeds the number of connections allowed by the Operating System. 4*60*500 = 120000 socket connections in 4 minutes ((4*60)/4)*500 = 30000 requests processed in 4 minutes 120000 - 30000 = 90000 open connections afer 4 minutes of peek time
That's a quite useless connection overload for async. request that won't care about the result of the execution. Best Regards, Utku On Thu, Feb 11, 2010 at 7:50 PM, David Reiss <[email protected]> wrote: > 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 >
