Issue with puma concurrency about ember-cli-rails HOT 4 CLOSED

I think the problem is that Ember-cli-rails is creating N ember instances for each worket. While debugging other problem i had i found that we shouldn't have more than 1 ember watch running over the same directory at a time. Ember CLI seems to be using tmp as a place to store some cache-related data. The result is like accessing the same no-threadsafe data set with two threads: a race condition.

I don't know too much of the code to know if there is some way to run one global ember process per folder (in a way similar to how zeus uses a .zeus.sock file) instead of one ember process per rails process (worker). It could be a better solution than the workaround.

from ember-cli-rails.

I think the problem is that Ember-cli-rails is creating N ember instances for each worket.

That is correct.

Honestly, I don't know how to detect multiple worker situation properly and consistently. The assumption was that this should only happen in development environment and people usually don't run multiple workers in development environment. Apparently it's false :)

from ember-cli-rails.

I think the problem is that, sometimes, it's easiest to just put gem "puma" and gem "unicorn-rails" in the main body of the Gemfile and making things without thinking of different environments. For example, we simply could make:

gem :webrick, :group => :development
gem :puma, :group => :production

But anyway, there is no assumption of just one worker and maybe in the future there could be a server which uses many workers everywhere and it could help to just have covered the situation of accidentally creating many embers.

Why do you think of using an empty file to detect if the ember process was already running?

from ember-cli-rails.

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

from ember-cli-rails.