Skip to content
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

Closed
sevos opened this issue Feb 13, 2015 · 7 comments
Closed

Unicorn in development with multiple workers does not work #85

sevos opened this issue Feb 13, 2015 · 7 comments

Comments

@sevos
Copy link
Contributor

sevos commented Feb 13, 2015

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.

@sevos
Copy link
Contributor Author

sevos commented Feb 13, 2015

I am probably gonna tackle it over the weekend. Any ideas are welcome.

@sevos
Copy link
Contributor Author

sevos commented Feb 16, 2015

I have found temporary solution for this. Simply put following code in after_fork of your unicorn configuration:

  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

@juliogarciag
Copy link

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 (.ember-cli-pid or similar). In this way, N rails workers can use the same ember process without making ember crash. (we can't have many ember watchers on the same folder at the same time because it leads to race conditions). I don't exactly how hard is to implement and i didn't think of some unexpected disadventage but i can help if any help is required :)

@sevos
Copy link
Contributor Author

sevos commented Feb 19, 2015

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.

@juliogarciag
Copy link

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?

@rondale-sc
Copy link
Collaborator

@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

@rwz
Copy link
Collaborator

rwz commented Mar 3, 2015

I've created a new issue to consolidate these two #94. Let's all move there.

@rwz rwz closed this as completed Mar 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants