Bring back REACT_NATIVE_WORKER_THREADS env var

mikemorris commented 6 years ago

Do you want to request a feature or report a bug?

Bringing back an old feature and improving documentation for CI build settings (like https://github.com/facebook/react-native/blob/2dc559d1fbab7434d61df62936be11434d6f7f91/.circleci/config.yml#L248-L249 and https://github.com/facebook/react-native/blob/2dc559d1fbab7434d61df62936be11434d6f7f91/.circleci/config.yml#L176).

What is the current behavior?

Worker threads can only be limited by the --max-workers command line flag, and not an environment variable.

This is mostly problematic when running inside a containerized CI environment like CircleCI, where the number of workers created may be proportional to the host machine CPUs instead of the allocated container resources and can lead to opaque errors that are difficult to diagnose and awkward to fix.

:app:bundleReleaseJsAndAssets FAILED
[17:52:11]: ▸ FAILURE: Build failed with an exception.
[17:52:11]: ▸ * What went wrong:
[17:52:11]: ▸ Execution failed for task ':app:bundleReleaseJsAndAssets'.
[17:52:11]: ▸ > Process 'command 'node'' finished with non-zero exit value 137
[17:52:11]: ▸ * Try:
[17:52:11]: ▸ Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
[17:52:11]: ▸ * Get more help at https://help.gradle.org
[17:52:11]: ▸ BUILD FAILED in 54s

This is compounded by the JVM seeing the host machine RAM instead of cgroup RAM. Some users have had success bundling manually and excluding the bundleJsReleaseAndAssets task from assembleRelease, so that the bundler is not attempting to run while the JVM is still hoarding memory, but that isn't a complete fix for this issue.

Passing a command line flag to the bundler task can be a bit awkward when it's wrapped by gradle and fastlane.

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.

I've triggered the OOM Killer in Circle CI once with https://github.com/mikemorris/ReactNativeApp (https://circleci.com/gh/mikemorris/ReactNativeApp/40), but it happens consistently on a private repo with several additional React Native module dependencies.

What is the expected behavior?

Setting REACT_NATIVE_WORKER_THREADS will limit the number of worker threads created.

This env var was removed in https://github.com/facebook/metro/commit/9127fce33c20a6f923a4abd0faf81478ed21e7ca and https://github.com/facebook/react-native/commit/29d9c35e122861d86c70b1e27a6e34eda4d82369, and was replaced with the --max-workers command line flag.

Setting REACT_NATIVE_WORKER_THREADS to limit Node.js workers is a recommended fix in a few threads, but no longer works.

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.

react-native@0.53.3 metro@0.24.7 node@8.9.3 npm@5.6.0 Docker Image api-27-node8-alpha from https://hub.docker.com/r/circleci/android/tags/ in CircleCI Ubuntu 16 host

smore9982 commented 6 years ago

My builds started working again after adding this to my build.gradle. It should pass in the max-workers parameter into react bundler.

project.ext.react = [ extraPackagerArgs: ["--max-workers=1"] ]

zibs commented 6 years ago

Thanks for both of these comments @smore9982 and @mikemorris - this fixed the issue we were having running on Circle CI in combination with fastlane flags param:

    gradle(
      task: "assemble",
      build_type: "Release",
      project_dir: "<path to project>"
      flags: "--no-daemon --max-workers 1"
)

facebook / metro

Bring back REACT_NATIVE_WORKER_THREADS env var #144