Multiple workers cause multiple build servers and race conditions

[rwz]

See issues #89 & #85.

[rwz]

First thing I'd like to understand: why people are even using multiple workers in dev environment.

If this is something people do a lot for legit reasons, we probably need to build some sort of workaround to support it. If it's very specific and rare, well, in this case a warning in a README stating that the gem is designed to work in a single-worker environment should be enough.

[himynameisjonas]

We try to have the exact same environment in development as we have in production, therefor we run thin as web server in all environments.

[rondale-sc]

@himynameisjonas I was under the impression that Thin doesn't have multiple workers. iirc

[himynameisjonas]

@rondale-sc oh, my misstake. I hade multiple servers running at the same time (Used to start 4 instances with http://pow.cx ). With just one server running Thin work fine.

[himynameisjonas]

But i use the same server in dev/prod for the reason i wrote in my first comment, but in this case i'm lucky we're running Thin and not puma/unicorn :)

[rondale-sc]

@himynameisjonas Glad that worked out. This shouldn't be an issue with production deploys because all ember-cli-rails does (if you asset precompile) is make the assets available to Rails which it does only once per ember app not per request.

This is only a problem when multiple workers are being used in development, which is not the default for puma (iirc).

Closing this for now. In #86 @sevos had a solution for this listed in his comment. I think that should suffice. Adding that to the readme might be a good idea. (what do you think @sevos?)

Cheers 🍻

[seanpdoyle]

@rondale-sc @rwz we use unicorn in development @ thoughtbot and we've recently run into this issue.