[
https://issues.apache.org/jira/browse/THRIFT-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gonyea updated THRIFT-1312:
---------------------------------
Attachment: thrift-1312.patch
> 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, 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
