[ https://issues.apache.org/jira/browse/THRIFT-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094177#comment-13094177 ]
Scott Gonyea commented on THRIFT-1312: -------------------------------------- Patch is now attached. > Add MutexableThreadPoolServer and ProcessPoolServer > --------------------------------------------------- > > Key: THRIFT-1312 > URL: https://issues.apache.org/jira/browse/THRIFT-1312 > Project: Thrift > Issue Type: New Feature > Components: Ruby - Library > Affects Versions: 0.7 > Reporter: Scott Gonyea > Fix For: 0.8 > > Attachments: thrift-1312.patch > > > Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" > and "ProcessPoolServer" to the Thrift Ruby Library. > The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, > as well as an example file that demonstrates its use. > Below is a lengthy description of how we make use of the MTPServer. But > before getting into that, you can find the code here, or in the included > patch. > https://github.com/sgonyea/thrift/tree/mtps/lib/rb > This draws very heavily from the ThreadPoolServer, except that it introduces > the use of Mutexes as one way to stop the server from spawning threads. > Further, it offers a #stop_threads method, that will check the state of each > thread and release control once all threads have finished serving requests to > clients. > Internally, this MTPServer is used in conjunction with HAProxy to shut down > and start up, cleanly, and to avoid all sorts of crazy race conditions that > often arise when serving over a raw socket. > When the MTPServer is started, it will fill the ThreadPool with N threads. > Once done, it is ready to receive requests and will yield to a callback if > one is supplied. In this callback, we call out to HAProxy and signal that we > are ready to begin accepting connections from API clients. > The parent application can be setup to trap any signals, as we do, and to > then lock the mutex (to prevent new threads from pooling). It then calls > @server.stop_threads. It also spins off another thread that will hard shut > down the server if Threads continue past an arbitrary amount of time. > The other benefit in using HAProxy is that it will close connections from > clients, if they are idle for some period of time. This prevents another > common issue, where a client remains connected and causes our Thread to > block, until the sun explodes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira