Wow. With that kind of volume, I agree that you need an internal queuing mechanism. Like I said - if you can produce a patch that would close sockets more quickly, I'd consider it for inclusion.
On Thu, Feb 11, 2010 at 10:05 AM, Utku Can Topçu <[email protected]> wrote: > 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 > > >
