[
https://issues.apache.org/jira/browse/THRIFT-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097710#comment-13097710
]
Scott Gonyea commented on THRIFT-1312:
--------------------------------------
New patch attached. I basically had to define "Thread" within the Thrift
namespace for the life of the spec, for the MutexableThreadPoolServer. The
reason is that RR was used for the mocks and it's "implemented_by" method does
not have any real parallel in RSpec's mocks (which the Thrift Ruby library
uses).
The MTPS server's specs are very thorough, making assertions
before/after/during the lambda that is passed into Thread.new. Which means
having to trap the block.
https://github.com/sgonyea/thrift/blob/80710a7cbf2e1fe35708293a2334d33da1deed36/lib/rb/spec/thrift/server/mutexable_thread_pool_server_spec.rb#L6-25
That highlights the hack that I use to make Thread.new behave how I want,
without ruining Thread.new for everything else :).
Please let me know if you have any trouble running this.
Also, I ran the tests using Ruby 1.8.7 and it's not behaving for me. Is the CI
server executing these specs in Ruby 1.8.7 or 1.9.2?
It'd be great if the CI server used rvm, because then we could "rvm exec
1.8.7,1.9.2,jruby,rbx some_ruby_spec_wrapper.sh" and make sure it works with
every major ruby.
> 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
