Fix multi threading issue - #8
Conversation
This means the Rails app needs to be declared before requiring this gem, so gem `zooplankton`, require: false And then `require “zooplankton”` in an initializer.
|
Hi! Thanks for this... I have to admit: I'm not really maintaining this gem much these days. I quickly read through the thread you linked and followed through to Evan's repro steps and the bug he files against MRI. It looks like the thread issue got fixed there in 2.3? What version of Ruby are you using? I noticed that TravisCI is mad, too... I bet we should update some test dependencies and also push up to the latest 2 point versions of Rails/Ruby? Threading issues are hard to test, but is there some way we could write a test that shows the thread problem? Or do you think the performance aspect is enough to warrant changes, regardless of whether the threading thing is still a problem in newer versions of MRI? I ask because I really dislike the interface of having to What do you think about all this stuff? |
|
Hi. Yeah I attempted to test it by spinning up multiple threads and using Zooplankton within them, to no avail. I deployed my branch to the production environment where this issue was surfacing (intermittently) and it seems to have stopped now. I agree re. the |
|
@ismasan What versions of Ruby and Rails are you using in production? |
|
I was on Rails 4.2.5 and Ruby 2.1.5 when I submitted this PR. Now I'm on 4.2.9 and 2.3.1 for the same app, so the threading issue might have gone away (it definitely went away even before the upgrade, after I started using this branch of Zooplankton). Still, it looks like the performance improvement alone would be nice to have, if I find the time to not make that |
See config.treat_symbols_as_metadata_keys_with_true_values = true
|
Ok I fixed one of the Travis errors by updating rspec. One more to go, the by now classic |
|
I've added a railtie that makes sure to load everything up once the Rails app is fully initialized. This means that the Tests pass by manually calling the new |
What
This PR pre-loads Rails' URL helpers into a module on startup time, to prevent multi-threading issues (ex. Puma) documented here: puma/puma#647
Context
I encountered sporadic issues when running this as part of a production app.
After some digging, everything points to the issue linked to above. The solution is to pre-load Rails' route helpers into a module instead of accessing them in run time.
This has the side benefit of improving performance (see below).
Installation
Unfortunately, this change means that Zooplankton needs to be required after the Rails application and routes have been defined. So you need this in your Gemfile:
And then require the gem in an initializer
Performance
Calling
Rails.application.routes.url_helpersdirectly seems to create a new module every time, which is slow. The solution is toinclude Rails.application.routes.url_helpersonce at startup time into our own module, and use that module in the library.I run a quick benchmark before and after this change.
So there seems to be a performance gain.
This is the benchmark script used (Ruby 2.3.1 on a MacBook Pro 3 GHz Intel Core i7, 16 GB 1600 MHz DDR3):