-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unicorn in development with multiple workers does not work #85
Comments
I am probably gonna tackle it over the weekend. Any ideas are welcome. |
I have found temporary solution for this. Simply put following code in if Rails.env.development?
if worker.nr > 0
EmberCLI.instance_eval do
each_app do |app|
def app.run
prepare
end
end
end
end
ObjectSpace.each_object EmberCLI::Middleware do |middleware|
middleware.send(:enable_ember_cli)
end
EmberCLI.wait!
end
|
I had a similar problem and i think we can maybe solve the main problem (N embers for N rails workers) by maybe keeping just one process alive per folder keeping the process PID in a hidden file ( |
Precisely, this is the problem. I'd to fix the root cause in the gems. This patch seems to work so far (I edited it few times). What also seems problematic is that ember watcher starts at the first request. (there might be two or more first requests). It lead sometimes to timeouts. This is why I start ember watcher at the start of first unicorn worker. |
Yes, the gem should start the watcher at initialize time i think. This is problematic but it's a subset of the main problem of allowing the creating of more than one ember. There is another issue of the same problem but using Puma workers and i need a general solution to having many embers would prevent aditional problems in the future for future web servers. The solution i mentioned is similar to what zeus does to prevent race conditions or similar complex scenarios: Keep a file with the process pid. In that way, the initialization would just create an ember process if there is no file and the process doesn't exist. If there's a file, don't create nothing and just keep going on. On exit, the gem kill the process and erase the file with the pid. No matter if we run 500 puma or unicorn workers, this ensures that there is only one ember process running in the folder. What do you think? |
@sevos Could you create a small repo that illustrates your error so that I could test this locally. I think this may be related to a few other issues. /cc @juliogarciag |
I've created a new issue to consolidate these two #94. Let's all move there. |
If you run Unicorn with more than 1 worker in development mode it works only on first load.
Modifying source code of the ember-cli app causes ENOTEMPTY exception, probably because there are more than 1
ember serve
processes trying to rebuild the project under the same directory.Lockfile seems to be ignored.
The text was updated successfully, but these errors were encountered: