[jira] [Updated] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

["Jake Farrell (Updated) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jake Farrell updated THRIFT-1312:
---------------------------------

    Fix Version/s:     (was: 0.8)
    
> 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
>         Attachments: thrift-1312.patch, thrift-1312.patch, thrift-1312.patch, thrift-1312.patch, 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira