passenger 5.0.10 → 5.0.11

data/doc/DebuggingAndStressTesting.md

@@ -26,7 +26,7 @@ Whenever a Phusion Passenger agent process crashes because of a signal (SIGABRT,
 
  * A simple libc-level backtrace of the current thread. This backtrace may or may not correspond to the thread that caused the crash.
  * A detailed backtrace report, covering all threads. This report even contains the values of variables on the stack. The report is obtained through the [crash-watch](https://github.com/FooBarWidget/crash-watch) tool so you must have it installed. Crash-watch in turn requires gdb, which must also be installed.
- * Agent-specific diagnostics information. For example the HelperAgent will report the status of its process pool and its connected clients.
+ * Agent-specific diagnostics information. For example the Passenger core will report the status of its process pool and its connected clients.
 
 You can change the crash behavior with the following environment variables:
 
@@ -55,6 +55,6 @@ To enable, set the environment variable `PASSENGER_SIMULATE_SYSCALL_FAILURES`. T
 
 `program_nameN` specifies the name of the Phusion Passenger process for which system call failure simulation should be enabled. This is followed by a list of system call `errno` names and the respective probabilities (between 0 and 1). For example:
 
-    export PASSENGER_SIMULATE_SYSCALL_FAILURES='watchdog=ENOSPC:0.01;server=EMFILE:0.001,ECONNREFUSED:0.02'
+    export PASSENGER_SIMULATE_SYSCALL_FAILURES='PassengerAgent watchdog=ENOSPC:0.01;PassengerAgent core=EMFILE:0.001,ECONNREFUSED:0.02'
 
-This will enable system call failure simulation only for the watchdog and the HTTP server, but not for the logging agent. All system calls in the watchdog will have a 1% probability of throwing ENOSPC. All system calls in the HTTP server will have a 0.1% probability of throwing EMFILE, and a 2% probability of throwing ECONNREFUSED.
+This will enable system call failure simulation only for the watchdog and the core, but not for the UstRouter. All system calls in the watchdog will have a 1% probability of throwing ENOSPC. All system calls in the HTTP server will have a 0.1% probability of throwing EMFILE, and a 2% probability of throwing ECONNREFUSED.

data/doc/Design and Architecture.html

@@ -1091,14 +1091,14 @@ pre {
 <div class="foo toclevel4"><a href="#_the_rationale_behind_reverse_proxying">1.1.2. The rationale behind reverse proxying</a></div>
 <div class="foo toclevel3"><a href="#_phusion_passenger_architecture_overview">1.2. Phusion Passenger architecture overview</a></div>
 <div class="foo toclevel4"><a href="#_web_server_module">1.2.1. Web server module</a></div>
-<div class="foo toclevel4"><a href="#_helperagent">1.2.2. HelperAgent</a></div>
-<div class="foo toclevel4"><a href="#_loggingagent">1.2.3. LoggingAgent</a></div>
+<div class="foo toclevel4"><a href="#_passenger_core">1.2.2. Passenger core</a></div>
+<div class="foo toclevel4"><a href="#_ustrouter">1.2.3. UstRouter</a></div>
 <div class="foo toclevel4"><a href="#_watchdog">1.2.4. Watchdog</a></div>
 <div class="foo toclevel4"><a href="#_command_line_tools">1.2.5. Command line tools</a></div>
 <div class="foo toclevel4"><a href="#_passenger_standalone">1.2.6. Passenger Standalone</a></div>
 <div class="foo toclevel3"><a href="#_build_system_and_source_tree">1.3. Build system and source tree</a></div>
 <div class="foo toclevel2"><a href="#_initialization">2. Initialization</a></div>
-<div class="foo toclevel2"><a href="#helper_agent_architecture">3. HelperAgent architecture</a></div>
+<div class="foo toclevel2"><a href="#passenger_core_architecture">3. Passenger core architecture</a></div>
 <div class="foo toclevel3"><a href="#_request_handling">3.1. Request handling</a></div>
 <div class="foo toclevel4"><a href="#_one_client_per_request">3.1.1. One client per request</a></div>
 <div class="foo toclevel4"><a href="#request_handler_forwarding_to_app">3.1.2. Forwarding to the application</a></div>
@@ -1254,31 +1254,31 @@ end</pre>
 <img src="images/passenger_architecture_overview.png" alt="An overview of Phusion Passenger’s architecture">
 </span></p></div>
 <div class="paragraph"><p>Phusion Passenger is not a single, monolithic entity. Instead, it consists of multiple components and processes that work together. Part of the reason why Phusion Passenger is split like this, is because it’s technically necessary (no other way to implement it). But another part of the reason is stability and robustness. Individual components can crash and can be restarted independently from each other. If we were to put everything inside a single process, then a crash will take down all of Phusion Passenger.</p></div>
-<div class="paragraph"><p>Thus, if the HelperAgent crashes, or if an application process crashes, they can both be restarted without affecting the web server’s stability.</p></div>
+<div class="paragraph"><p>Thus, if the Passenger core crashes, or if an application process crashes, they can both be restarted without affecting the web server’s stability.</p></div>
 <div class="sect3">
 <span class="anchor_helper" id="_web_server_module"></span><h4 data-anchor="_web_server_module">1.2.1. Web server module</h4>
-<div class="paragraph"><p>When an HTTP client sends a request, it is received by the web server (Nginx or Apache). Both Apache and Nginx can be extended with <strong>modules</strong>. Phusion Passenger provides such a module. The module is loaded into Nginx/Apache. It checks whether the request should be handled by a Phusion Passenger-served web application, and if so, forwards the request to the HelperAgent. The internal wire protocol used during this forwarding, is a modified version of <a href="http://en.wikipedia.org/wiki/SCGI">SCGI</a>.</p></div>
-<div class="paragraph"><p>The Nginx module and Apache module have an entirely different code base. Their code bases are in <span class="monospaced">ext/nginx</span> and <span class="monospaced">ext/apache2</span>, respectively. Both modules are relatively small because they outsource most logic to the HelperAgent, and because they utilize a common library (<span class="monospaced">ext/common</span>). This allows us to support both Nginx and Apache without having to write a lot of things twice.</p></div>
+<div class="paragraph"><p>When an HTTP client sends a request, it is received by the web server (Nginx or Apache). Both Apache and Nginx can be extended with <strong>modules</strong>. Phusion Passenger provides such a module. The module is loaded into Nginx/Apache. It checks whether the request should be handled by a Phusion Passenger-served web application, and if so, forwards the request to the Passenger core. The internal wire protocol used during this forwarding, is a modified version of <a href="http://en.wikipedia.org/wiki/SCGI">SCGI</a>.</p></div>
+<div class="paragraph"><p>The Nginx module and Apache module have an entirely different code base. Their code bases are in <span class="monospaced">ext/nginx</span> and <span class="monospaced">ext/apache2</span>, respectively. Both modules are relatively small because they outsource most logic to the Passenger core, and because they utilize a common library (<span class="monospaced">ext/common</span>). This allows us to support both Nginx and Apache without having to write a lot of things twice.</p></div>
 </div>
 <div class="sect3">
-<span class="anchor_helper" id="_helperagent"></span><h4 data-anchor="_helperagent">1.2.2. HelperAgent</h4>
-<div class="paragraph"><p>The <strong>HelperAgent</strong> is Phusion Passenger’s core, where most of the processing is done. The HelperAgent keeps track of which application processes currently exist, and using load balancing rules, determines which process a request should be forwarded to. The HelperAgent also takes care of <strong>application spawning</strong>: if it determines that having more application processes is necessary or beneficial, then it will make that happen. Process spawning is subject to user-configured limits: the HelperAgent will never spawn more processes than a user-configured maximum.</p></div>
-<div class="paragraph"><p>The HelperAgent also has monitoring and statistics gathering capabilities. It constantly keeps track of applications' memory usage, how many requests they’ve handled, etc. This information can later be queried from administration tools. And if an application process crashes, the HelperAgent restarts it.</p></div>
-<div class="paragraph"><p>The HelperAgent is by far the largest and most complex part of the system, but it is itself composed of several smaller subsystems. Most of the <a href="#helper_agent_architecture">HelperAgent architecture</a> chapter is devoted to describing the HelperAgent.</p></div>
+<span class="anchor_helper" id="_passenger_core"></span><h4 data-anchor="_passenger_core">1.2.2. Passenger core</h4>
+<div class="paragraph"><p>The <strong>Passenger core</strong> is where most of the processing is done. The core keeps track of which application processes currently exist, and using load balancing rules, determines which process a request should be forwarded to. The core also takes care of <strong>application spawning</strong>: if it determines that having more application processes is necessary or beneficial, then it will make that happen. Process spawning is subject to user-configured limits: the core will never spawn more processes than a user-configured maximum.</p></div>
+<div class="paragraph"><p>The core also has monitoring and statistics gathering capabilities. It constantly keeps track of applications' memory usage, how many requests they’ve handled, etc. This information can later be queried from administration tools. And if an application process crashes, the core restarts it.</p></div>
+<div class="paragraph"><p>The core is by far the largest and most complex part of the system, but it is itself composed of several smaller subsystems. Most of the <a href="#passenger_core_architecture">core architecture</a> chapter is devoted to describing the core.</p></div>
 </div>
 <div class="sect3">
-<span class="anchor_helper" id="_loggingagent"></span><h4 data-anchor="_loggingagent">1.2.3. LoggingAgent</h4>
-<div class="paragraph"><p>The HelperAgent cooperates with the <strong>LoggingAgent</strong>. This latter is responsible for sending data to <a href="https://www.unionstationapp.com">Union Station</a>, a monitoring web service. If you didn’t explicitly tell Phusion Passenger to send data to Union Station, then the LoggingAgent sits idle and does not consume resources.</p></div>
+<span class="anchor_helper" id="_ustrouter"></span><h4 data-anchor="_ustrouter">1.2.3. UstRouter</h4>
+<div class="paragraph"><p>The core cooperates with the <strong>UstRouter</strong>. This latter is responsible for sending data to <a href="https://www.unionstationapp.com">Union Station</a>, a monitoring web service. If you didn’t explicitly tell Phusion Passenger to send data to Union Station, then the UstRouter sits idle and does not consume resources.</p></div>
 </div>
 <div class="sect3">
 <span class="anchor_helper" id="_watchdog"></span><h4 data-anchor="_watchdog">1.2.4. Watchdog</h4>
-<div class="paragraph"><p>The HelperAgent and the LoggingAgent contain complex logic, so they could contain bugs which could crash them.
+<div class="paragraph"><p>The core and the UstRouter contain complex logic, so they could contain bugs which could crash them.
 So as a safety measure, they are both monitored by the <strong>Watchdog</strong>. If either of them crash, they are restarted by the Watchdog. This setup seeks to ensure that the system stays up, no matter what.</p></div>
 <div class="paragraph"><p>You might now wonder: what happens if the Watchdog crashes? Shouldn’t the Watchdog be monitored by another Watchdog? We’ve contemplated this possibility, but the Watchdog is very simple, and since 2012 we haven’t seen a single report of the Watchdog crashing, nor have we been able to make it crash since that time. So, for the sake of keeping the codebase as simple as possible, we’ve chosen not to introduce multiple Watchdogs.</p></div>
 </div>
 <div class="sect3">
 <span class="anchor_helper" id="_command_line_tools"></span><h4 data-anchor="_command_line_tools">1.2.5. Command line tools</h4>
-<div class="paragraph"><p>Finally, there is an array of <strong>command line tools</strong> which support Phusion Passenger. The installers — <span class="monospaced">passenger-install-*-module</span> — are responsible for installing Phusion Passenger. There are administrative tools such as <span class="monospaced">passenger-status</span> and <span class="monospaced">passenger-memory-stats</span>. And many more. Some of these tools may communicate with one of the agents. For example, the <span class="monospaced">passenger-status</span> queries the HelperAgent for information that the HelperAgent has collected. How this communication is done, is described in <a href="#instance_state_and_communication">Instance state and communication</a>.</p></div>
+<div class="paragraph"><p>Finally, there is an array of <strong>command line tools</strong> which support Phusion Passenger. The installers — <span class="monospaced">passenger-install-*-module</span> — are responsible for installing Phusion Passenger. There are administrative tools such as <span class="monospaced">passenger-status</span> and <span class="monospaced">passenger-memory-stats</span>. And many more. Some of these tools may communicate with one of the agents. For example, the <span class="monospaced">passenger-status</span> queries the core for information that the core has collected. How this communication is done, is described in <a href="#instance_state_and_communication">Instance state and communication</a>.</p></div>
 </div>
 <div class="sect3">
 <span class="anchor_helper" id="_passenger_standalone"></span><h4 data-anchor="_passenger_standalone">1.2.6. Passenger Standalone</h4>
@@ -1287,7 +1287,7 @@ So as a safety measure, they are both monitored by the <strong>Watchdog</strong>
 </div>
 <div class="sect2">
 <span class="anchor_helper" id="_build_system_and_source_tree"></span><h3 data-anchor="_build_system_and_source_tree">1.3. Build system and source tree</h3>
-<div class="paragraph"><p>Phusion Passenger is written mostly in C++ and Ruby. The web server modules, HelperAgent, LoggingAgent and Watchdog are written in C++. Most command line tools are written in Ruby. You can find each component here:</p></div>
+<div class="paragraph"><p>Phusion Passenger is written mostly in C++ and Ruby. The web server modules, core, UstRouter and Watchdog are written in C++. Most command line tools are written in Ruby. You can find each component here:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
@@ -1296,7 +1296,7 @@ The web server modules can be found in <span class="monospaced">ext/apache2</spa
 </li>
 <li>
 <p>
-The HelperAgent, LoggingAgent and Watchdog can be found in <span class="monospaced">ext/common/agents</span>.
+The Passenger core, UstRouter and Watchdog can be found in <span class="monospaced">ext/common/agent</span>.
 </p>
 </li>
 <li>
@@ -1346,17 +1346,17 @@ The Phusion Passenger module inside Nginx/Apache proceeds with starting the Watc
 </li>
 <li>
 <p>
-The Watchdog first initializes a <a href="#instance_state_and_communication">"instance directory"</a>, which is a temporary directory containing files that will be used during the life time of this Phusion Passenger instance. For example, the directory contains Unix domain socket files, so that the different Phusion Passenger processes can communicate with each other. The Watchdog is implemented in <span class="monospaced">ext/common/agents/Watchdog/Main.cpp</span>.
+The Watchdog first initializes a <a href="#instance_state_and_communication">"instance directory"</a>, which is a temporary directory containing files that will be used during the life time of this Phusion Passenger instance. For example, the directory contains Unix domain socket files, so that the different Phusion Passenger processes can communicate with each other. The Watchdog is implemented in <span class="monospaced">ext/common/agent/Watchdog/Main.cpp</span>.
 </p>
 </li>
 <li>
 <p>
-The Watchdog starts the HelperAgent and the LoggingAgent simultaneously. Each performs its own initialization.
+The Watchdog starts the Passenger core and the UstRouter simultaneously. Each performs its own initialization.
 </p>
 </li>
 <li>
 <p>
-When the HelperAgent is done initializing, it will send a message back to the Watchdog saying that it’s done. The LoggingAgent does something similar. When the Watchdog has received both acknowledgment messages, it finishes initialization. If the Watchdog notices that one of the agents have exited without sending an acknowledgment message, then it enters an error state.
+When the core is done initializing, it will send a message back to the Watchdog saying that it’s done. The UstRouter does something similar. When the Watchdog has received both acknowledgment messages, it finishes initialization. If the Watchdog notices that one of the agents have exited without sending an acknowledgment message, then it enters an error state.
 </p>
 </li>
 <li>
@@ -1369,19 +1369,19 @@ The Watchdog reports successful startup back to the Phusion Passenger module tha
 </div>
 </div>
 <div class="sect1">
-<span class="anchor_helper" id="helper_agent_architecture"></span><h2 data-anchor="helper_agent_architecture">3. HelperAgent architecture</h2>
+<span class="anchor_helper" id="passenger_core_architecture"></span><h2 data-anchor="passenger_core_architecture">3. Passenger core architecture</h2>
 <div class="sectionbody">
 <div class="paragraph"><p><span class="image">
-<img src="images/helper_agent_core_architecture.png" alt="HelperAgent architecture">
+<img src="images/passenger_core_architecture.png" alt="Passenger core architecture">
 </span></p></div>
-<div class="paragraph"><p>The HelperAgent consists of two subsystems. One is the <strong>request handling subsystem</strong>. The other is <strong>the ApplicationPool subsystem</strong>, which performs the bulk of process management. The HelperAgent also uses a number of support libraries. The largest third-party support libraries are shown in the diagram. Many more — internal — support libraries are used, but they’re omitted from the diagram. You can find these internal support libraries in the directory <span class="monospaced">ext/common/Utils</span>.</p></div>
+<div class="paragraph"><p>The Passenger core consists of two subsystems. One is the <strong>request handling subsystem</strong>. The other is <strong>the ApplicationPool subsystem</strong>, which performs the bulk of process management. The core also uses a number of support libraries. The largest third-party support libraries are shown in the diagram. Many more — internal — support libraries are used, but they’re omitted from the diagram. You can find these internal support libraries in the directory <span class="monospaced">ext/common/Utils</span>.</p></div>
 <div class="sect2">
 <span class="anchor_helper" id="_request_handling"></span><h3 data-anchor="_request_handling">3.1. Request handling</h3>
-<div class="paragraph"><p>Recall that requests are first received from the web server. The web server serializes the request into a slightly modified version of <a href="http://en.wikipedia.org/wiki/SCGI">the SCGI format</a>, and sends it to the HelperAgent’s RequestHandler. The RequestHandler performs some work, and eventually sends back a regular HTTP response. The web server parses the RequestHandler response, and sends a response to the original HTTP client.</p></div>
+<div class="paragraph"><p>Recall that requests are first received from the web server. The web server serializes the request into a slightly modified version of <a href="http://en.wikipedia.org/wiki/SCGI">the SCGI format</a>, and sends it to the core’s RequestHandler. The RequestHandler performs some work, and eventually sends back a regular HTTP response. The web server parses the RequestHandler response, and sends a response to the original HTTP client.</p></div>
 <div class="paragraph"><p>The RequestHandler listens on a Unix domain socket file. This Unix domain socket file is called <span class="monospaced">request</span>, and is located in <a href="#instance_state_and_communication">the instance directory</a>.</p></div>
 <div class="sect3">
 <span class="anchor_helper" id="_one_client_per_request"></span><h4 data-anchor="_one_client_per_request">3.1.1. One client per request</h4>
-<div class="paragraph"><p>The web server creates a new connection to the HelperAgent on every request. Thus, from the viewpoint of the RequestHandler, its client is the web server. Every time a client connects (i.e. a new request is forwarded), the RequestHandler creates a new Client object which represents that request. All request-specific state is stored inside the Client. After the RequestHandler is done processing a request, it closes the client socket.</p></div>
+<div class="paragraph"><p>The web server creates a new connection to the core on every request. Thus, from the viewpoint of the RequestHandler, its client is the web server. Every time a client connects (i.e. a new request is forwarded), the RequestHandler creates a new Client object which represents that request. All request-specific state is stored inside the Client. After the RequestHandler is done processing a request, it closes the client socket.</p></div>
 <div class="paragraph"><p>Note that in the diagram, a Client has a 0..1 association with RequestHandler. That’s because when a Client is disconnected, the pointer to the associated RequestHandler is set to NULL. There might be background operations left which still have a pointer to the Client. As soon as those background operations finish, they check whether the Client has a valid pointer to the RequestHandler. If so, they commit their work; if not, they discard their work. The Client is destroyed when all its associated background operations have finished.</p></div>
 </div>
 <div class="sect3">
@@ -1539,7 +1539,7 @@ DummySpawner (not shown in diagram) — only used in unit tests.
 <div class="sect1">
 <span class="anchor_helper" id="app_spawning_and_loading"></span><h2 data-anchor="app_spawning_and_loading">4. Application spawning and loading</h2>
 <div class="sectionbody">
-<div class="paragraph"><p>Application processes are spawned from the HelperAgent process. Spawning a process involves a lot of <strong>preparation work</strong>, such as setting up communication channels, setting up the current working directory, environment variables, etc. This preparation work is done by <a href="#spawner_subsystem">a Spawner object</a>, together with various support executables.</p></div>
+<div class="paragraph"><p>Application processes are spawned from the Passenger core process. Spawning a process involves a lot of <strong>preparation work</strong>, such as setting up communication channels, setting up the current working directory, environment variables, etc. This preparation work is done by <a href="#spawner_subsystem">a Spawner object</a>, together with various support executables.</p></div>
 <div class="paragraph"><p>When preparation is done, your application’s entry point has to be loaded somehow. That loading is done through a language-specific <strong>loader program</strong>. The loader program communicates with the Spawner through the communication channel that was set up earlier, initializes the language-specific environment, sets up a server, and reports back to the Spawner. This communication is done through a certain <strong>protocol</strong>.</p></div>
 <div class="sect2">
 <span class="anchor_helper" id="_preparation_work"></span><h3 data-anchor="_preparation_work">4.1. Preparation work</h3>
@@ -1553,7 +1553,7 @@ DummySpawner (not shown in diagram) — only used in unit tests.
 </div>
 <div class="sect3">
 <span class="anchor_helper" id="_loading_spawnpreparer_possibly_through_bash"></span><h4 data-anchor="_loading_spawnpreparer_possibly_through_bash">4.1.2. Loading SpawnPreparer, possibly through bash</h4>
-<div class="paragraph"><p>Because the HelperAgent is heavily multi-threaded, the child process has been forked by the Spawner <a href="http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html">may only perform async-signal-safe operations</a>:</p></div>
+<div class="paragraph"><p>Because the Passenger core is heavily multi-threaded, the child process has been forked by the Spawner <a href="http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html">may only perform async-signal-safe operations</a>:</p></div>
 <div class="quoteblock">
 <div class="content">"A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls."</div>
 <div class="attribution">
@@ -1772,7 +1772,7 @@ The maximum number of <strong>concurrent connections</strong> the server support
 <div class="olist arabic"><ol class="arabic">
 <li>
 <p>
-Just write the error message to stdout as you normally do, and abort without printing the <span class="monospaced">!&gt; Ready</span> message. The HelperAgent will read everything that the loader has written to stdout, and use it as the error message. This error message is considered to be plain text.
+Just write the error message to stdout as you normally do, and abort without printing the <span class="monospaced">!&gt; Ready</span> message. The Passenger core will read everything that the loader has written to stdout, and use it as the error message. This error message is considered to be plain text.
 </p>
 </li>
 <li>
@@ -1802,7 +1802,7 @@ No more clients will be routed to this particular process.
 </div>
 <div class="sect3">
 <span class="anchor_helper" id="_stdout_and_stderr_forwarding"></span><h4 data-anchor="_stdout_and_stderr_forwarding">4.2.7. Stdout and stderr forwarding</h4>
-<div class="paragraph"><p>All lines that the loader writes to stdout, and that are not prefixed with `!&gt; `, are forwarded by the HelperAgent to its own stdout. Similarly, everything that the loader writes to stderr, whether prefixed with `!&gt; ` or not, is forwarded by the HelperAgent to its own stdout.</p></div>
+<div class="paragraph"><p>All lines that the loader writes to stdout, and that are not prefixed with `!&gt; `, are forwarded by the Passenger core to its own stdout. Similarly, everything that the loader writes to stderr, whether prefixed with `!&gt; ` or not, is forwarded by the Passenger core to its own stdout.</p></div>
 <div class="paragraph"><p>While the Spawner is still doing its work, it takes care of this forwarding by itself. Once the Spawner is done, it outsources this work to two PipeWatcher objects, each which spawns a background thread for this purpose.</p></div>
 </div>
 </div>
@@ -1838,7 +1838,7 @@ It sends a response back to the Spawner. This is similar to how the loader does
 </div>
 <div class="sect2">
 <span class="anchor_helper" id="app_types_registry"></span><h3 data-anchor="app_types_registry">4.4. The AppTypes registry</h3>
-<div class="paragraph"><p>When the web server receives a request, the Phusion Passenger module inside it autodetects the type of application that the request belongs to. It does that by examening the filesystem and checking which one of the startup files exist. For example, if <span class="monospaced">config.ru</span> exists, then it assumes that it’s a Ruby app. Or if <span class="monospaced">app.js</span> exists, then it assumes that it’s a Node.js app. The Phusion Passenger module forwards the inferred application type to the HelperAgent.</p></div>
+<div class="paragraph"><p>When the web server receives a request, the Phusion Passenger module inside it autodetects the type of application that the request belongs to. It does that by examening the filesystem and checking which one of the startup files exist. For example, if <span class="monospaced">config.ru</span> exists, then it assumes that it’s a Ruby app. Or if <span class="monospaced">app.js</span> exists, then it assumes that it’s a Node.js app. The Phusion Passenger module forwards the inferred application type to the Passenger core.</p></div>
 <div class="paragraph"><p>Given an application type, the associated loader and preloader can be looked up.</p></div>
 <div class="paragraph"><p>Information about the supported application types, startup files, loaders and preloaders are defined in the following places:</p></div>
 <div class="ulist"><ul>
@@ -1869,7 +1869,7 @@ The method <span class="monospaced">looks_like_app_directory?</span> in the file
 <div class="sect1">
 <span class="anchor_helper" id="instance_state_and_communication"></span><h2 data-anchor="instance_state_and_communication">5. Instance state and communication</h2>
 <div class="sectionbody">
-<div class="paragraph"><p>Every time you start Phusion Passenger, you’ve created a new <strong>instance</strong>. Every instance consists of multiple processes that work together (Watchdog, HelperAgent, LoggingAgent, application processes). All those processes have to be able to communicate with each other. Those processes must also <strong>not</strong> communicate with the processes belonging to other instances. For example, if you start Apache+Passenger <strong>and</strong> Nginx+Passenger, then we don’t want the HelperAgent that’s started from Apache to use LoggingAgent that’s started from Nginx.</p></div>
+<div class="paragraph"><p>Every time you start Phusion Passenger, you’ve created a new <strong>instance</strong>. Every instance consists of multiple processes that work together (Watchdog, Passenger core, UstRouter, application processes). All those processes have to be able to communicate with each other. Those processes must also <strong>not</strong> communicate with the processes belonging to other instances. For example, if you start Apache+Passenger <strong>and</strong> Nginx+Passenger, then we don’t want the Passenger core that’s started from Apache to use UstRouter that’s started from Nginx.</p></div>
 <div class="paragraph"><p>Clearly, the processes can’t listen on a specific TCP port for communication. Nor can they listen on a fixed Unix domain socket filename.</p></div>
 <div class="paragraph"><p>That is where the <em>instance directory</em> comes in. Every Phusion Passenger instance has its own, unique temporary directory. That directory is removed when the instance halts. The directory contains Unix domain socket files that the processes listen on. Every Phusion Passenger related process knows where its own instance directory is, and thus, knows how to communicate with other processes belonging to the same instance. The instance directory is implemented in <span class="monospaced">ext/common/InstanceDirectory.h</span>.</p></div>
 <div class="paragraph"><p>Administration tools such as <span class="monospaced">passenger-status</span> query information using instance directories. First, they check which instance directories exist on the system. If they find only one, then they query the sockets inside that sole instance directory. Otherwise, they abort with an error and ask the user to specifically select the instance to query.</p></div>

data/doc/Design and Architecture.txt

@@ -92,36 +92,36 @@ image:images/passenger_architecture_overview.png[An overview of Phusion Passenge
 
 Phusion Passenger is not a single, monolithic entity. Instead, it consists of multiple components and processes that work together. Part of the reason why Phusion Passenger is split like this, is because it's technically necessary (no other way to implement it). But another part of the reason is stability and robustness. Individual components can crash and can be restarted independently from each other. If we were to put everything inside a single process, then a crash will take down all of Phusion Passenger.
 
-Thus, if the HelperAgent crashes, or if an application process crashes, they can both be restarted without affecting the web server's stability.
+Thus, if the Passenger core crashes, or if an application process crashes, they can both be restarted without affecting the web server's stability.
 
 ==== Web server module
 
-When an HTTP client sends a request, it is received by the web server (Nginx or Apache). Both Apache and Nginx can be extended with **modules**. Phusion Passenger provides such a module. The module is loaded into Nginx/Apache. It checks whether the request should be handled by a Phusion Passenger-served web application, and if so, forwards the request to the HelperAgent. The internal wire protocol used during this forwarding, is a modified version of link:http://en.wikipedia.org/wiki/SCGI[SCGI].
+When an HTTP client sends a request, it is received by the web server (Nginx or Apache). Both Apache and Nginx can be extended with **modules**. Phusion Passenger provides such a module. The module is loaded into Nginx/Apache. It checks whether the request should be handled by a Phusion Passenger-served web application, and if so, forwards the request to the Passenger core. The internal wire protocol used during this forwarding, is a modified version of link:http://en.wikipedia.org/wiki/SCGI[SCGI].
 
-The Nginx module and Apache module have an entirely different code base. Their code bases are in `ext/nginx` and `ext/apache2`, respectively. Both modules are relatively small because they outsource most logic to the HelperAgent, and because they utilize a common library (`ext/common`). This allows us to support both Nginx and Apache without having to write a lot of things twice.
+The Nginx module and Apache module have an entirely different code base. Their code bases are in `ext/nginx` and `ext/apache2`, respectively. Both modules are relatively small because they outsource most logic to the Passenger core, and because they utilize a common library (`ext/common`). This allows us to support both Nginx and Apache without having to write a lot of things twice.
 
-==== HelperAgent
+==== Passenger core
 
-The **HelperAgent** is Phusion Passenger's core, where most of the processing is done. The HelperAgent keeps track of which application processes currently exist, and using load balancing rules, determines which process a request should be forwarded to. The HelperAgent also takes care of **application spawning**: if it determines that having more application processes is necessary or beneficial, then it will make that happen. Process spawning is subject to user-configured limits: the HelperAgent will never spawn more processes than a user-configured maximum.
+The **Passenger core** is where most of the processing is done. The core keeps track of which application processes currently exist, and using load balancing rules, determines which process a request should be forwarded to. The core also takes care of **application spawning**: if it determines that having more application processes is necessary or beneficial, then it will make that happen. Process spawning is subject to user-configured limits: the core will never spawn more processes than a user-configured maximum.
 
-The HelperAgent also has monitoring and statistics gathering capabilities. It constantly keeps track of applications' memory usage, how many requests they've handled, etc. This information can later be queried from administration tools. And if an application process crashes, the HelperAgent restarts it.
+The core also has monitoring and statistics gathering capabilities. It constantly keeps track of applications' memory usage, how many requests they've handled, etc. This information can later be queried from administration tools. And if an application process crashes, the core restarts it.
 
-The HelperAgent is by far the largest and most complex part of the system, but it is itself composed of several smaller subsystems. Most of the <<helper_agent_architecture,HelperAgent architecture>> chapter is devoted to describing the HelperAgent.
+The core is by far the largest and most complex part of the system, but it is itself composed of several smaller subsystems. Most of the <<passenger_core_architecture,core architecture>> chapter is devoted to describing the core.
 
-==== LoggingAgent
+==== UstRouter
 
-The HelperAgent cooperates with the **LoggingAgent**. This latter is responsible for sending data to link:https://www.unionstationapp.com[Union Station], a monitoring web service. If you didn't explicitly tell Phusion Passenger to send data to Union Station, then the LoggingAgent sits idle and does not consume resources.
+The core cooperates with the **UstRouter**. This latter is responsible for sending data to link:https://www.unionstationapp.com[Union Station], a monitoring web service. If you didn't explicitly tell Phusion Passenger to send data to Union Station, then the UstRouter sits idle and does not consume resources.
 
 ==== Watchdog
 
-The HelperAgent and the LoggingAgent contain complex logic, so they could contain bugs which could crash them.
+The core and the UstRouter contain complex logic, so they could contain bugs which could crash them.
 So as a safety measure, they are both monitored by the **Watchdog**. If either of them crash, they are restarted by the Watchdog. This setup seeks to ensure that the system stays up, no matter what.
 
 You might now wonder: what happens if the Watchdog crashes? Shouldn't the Watchdog be monitored by another Watchdog? We've contemplated this possibility, but the Watchdog is very simple, and since 2012 we haven't seen a single report of the Watchdog crashing, nor have we been able to make it crash since that time. So, for the sake of keeping the codebase as simple as possible, we've chosen not to introduce multiple Watchdogs.
 
 ==== Command line tools
 
-Finally, there is an array of **command line tools** which support Phusion Passenger. The installers -- `passenger-install-*-module` -- are responsible for installing Phusion Passenger. There are administrative tools such as `passenger-status` and `passenger-memory-stats`. And many more. Some of these tools may communicate with one of the agents. For example, the `passenger-status` queries the HelperAgent for information that the HelperAgent has collected. How this communication is done, is described in <<instance_state_and_communication,Instance state and communication>>.
+Finally, there is an array of **command line tools** which support Phusion Passenger. The installers -- `passenger-install-*-module` -- are responsible for installing Phusion Passenger. There are administrative tools such as `passenger-status` and `passenger-memory-stats`. And many more. Some of these tools may communicate with one of the agents. For example, the `passenger-status` queries the core for information that the core has collected. How this communication is done, is described in <<instance_state_and_communication,Instance state and communication>>.
 
 ==== Passenger Standalone
 
@@ -129,10 +129,10 @@ You might have noticed that Phusion Passenger Standalone is not part of the diag
 
 === Build system and source tree
 
-Phusion Passenger is written mostly in C\++ and Ruby. The web server modules, HelperAgent, LoggingAgent and Watchdog are written in C++. Most command line tools are written in Ruby. You can find each component here:
+Phusion Passenger is written mostly in C\++ and Ruby. The web server modules, core, UstRouter and Watchdog are written in C++. Most command line tools are written in Ruby. You can find each component here:
 
  * The web server modules can be found in `ext/apache2` and `ext/nginx`.
- * The HelperAgent, LoggingAgent and Watchdog can be found in `ext/common/agents`.
+ * The Passenger core, UstRouter and Watchdog can be found in `ext/common/agent`.
  * The command line tools can be found in `bin`, with some parts of their code in `lib`.
 
 More information can be found in the link:https://github.com/phusion/passenger/blob/master/CONTRIBUTING.md[Contributors Guide]. This guide also teaches you how to compile Phusion Passenger.
@@ -152,33 +152,33 @@ Phusion Passenger initializes as follows.
  * `ext/apache2/Hooks.cpp`, in the constructor for the `Hooks` class.
  * `ext/common/AgentsStarter.h` and `AgentsStarter.cpp`. Most of the logic pertaining starting the Watchdog is in this file.
 
-3. The Watchdog first initializes a <<instance_state_and_communication,"instance directory">>, which is a temporary directory containing files that will be used during the life time of this Phusion Passenger instance. For example, the directory contains Unix domain socket files, so that the different Phusion Passenger processes can communicate with each other. The Watchdog is implemented in `ext/common/agents/Watchdog/Main.cpp`.
+3. The Watchdog first initializes a <<instance_state_and_communication,"instance directory">>, which is a temporary directory containing files that will be used during the life time of this Phusion Passenger instance. For example, the directory contains Unix domain socket files, so that the different Phusion Passenger processes can communicate with each other. The Watchdog is implemented in `ext/common/agent/Watchdog/Main.cpp`.
 
-4. The Watchdog starts the HelperAgent and the LoggingAgent simultaneously. Each performs its own initialization.
+4. The Watchdog starts the Passenger core and the UstRouter simultaneously. Each performs its own initialization.
 
-5. When the HelperAgent is done initializing, it will send a message back to the Watchdog saying that it's done. The LoggingAgent does something similar. When the Watchdog has received both acknowledgment messages, it finishes initialization. If the Watchdog notices that one of the agents have exited without sending an acknowledgment message, then it enters an error state.
+5. When the core is done initializing, it will send a message back to the Watchdog saying that it's done. The UstRouter does something similar. When the Watchdog has received both acknowledgment messages, it finishes initialization. If the Watchdog notices that one of the agents have exited without sending an acknowledgment message, then it enters an error state.
 
 6. The Watchdog reports successful startup back to the Phusion Passenger module that's running inside Nginx/Apache. Or, if initialization didn't success, the Watchdog reports back an error. The Phusion Passenger module inside Nginx/Apache then logs the error.
 
 After initialization, Phusion Passenger is ready to receive and to process requests.
 
 
-[[helper_agent_architecture]]
-== HelperAgent architecture
+[[passenger_core_architecture]]
+== Passenger core architecture
 
-image:images/helper_agent_core_architecture.png[HelperAgent architecture]
+image:images/passenger_core_architecture.png[Passenger core architecture]
 
-The HelperAgent consists of two subsystems. One is the *request handling subsystem*. The other is *the ApplicationPool subsystem*, which performs the bulk of process management. The HelperAgent also uses a number of support libraries. The largest third-party support libraries are shown in the diagram. Many more -- internal -- support libraries are used, but they're omitted from the diagram. You can find these internal support libraries in the directory `ext/common/Utils`.
+The Passenger core consists of two subsystems. One is the *request handling subsystem*. The other is *the ApplicationPool subsystem*, which performs the bulk of process management. The core also uses a number of support libraries. The largest third-party support libraries are shown in the diagram. Many more -- internal -- support libraries are used, but they're omitted from the diagram. You can find these internal support libraries in the directory `ext/common/Utils`.
 
 === Request handling
 
-Recall that requests are first received from the web server. The web server serializes the request into a slightly modified version of link:http://en.wikipedia.org/wiki/SCGI[the SCGI format], and sends it to the HelperAgent's RequestHandler. The RequestHandler performs some work, and eventually sends back a regular HTTP response. The web server parses the RequestHandler response, and sends a response to the original HTTP client.
+Recall that requests are first received from the web server. The web server serializes the request into a slightly modified version of link:http://en.wikipedia.org/wiki/SCGI[the SCGI format], and sends it to the core's RequestHandler. The RequestHandler performs some work, and eventually sends back a regular HTTP response. The web server parses the RequestHandler response, and sends a response to the original HTTP client.
 
 The RequestHandler listens on a Unix domain socket file. This Unix domain socket file is called `request`, and is located in <<instance_state_and_communication,the instance directory>>.
 
 ==== One client per request
 
-The web server creates a new connection to the HelperAgent on every request. Thus, from the viewpoint of the RequestHandler, its client is the web server. Every time a client connects (i.e. a new request is forwarded), the RequestHandler creates a new Client object which represents that request. All request-specific state is stored inside the Client. After the RequestHandler is done processing a request, it closes the client socket.
+The web server creates a new connection to the core on every request. Thus, from the viewpoint of the RequestHandler, its client is the web server. Every time a client connects (i.e. a new request is forwarded), the RequestHandler creates a new Client object which represents that request. All request-specific state is stored inside the Client. After the RequestHandler is done processing a request, it closes the client socket.
 
 Note that in the diagram, a Client has a 0..1 association with RequestHandler. That's because when a Client is disconnected, the pointer to the associated RequestHandler is set to NULL. There might be background operations left which still have a pointer to the Client. As soon as those background operations finish, they check whether the Client has a valid pointer to the RequestHandler. If so, they commit their work; if not, they discard their work. The Client is destroyed when all its associated background operations have finished.
 
@@ -257,7 +257,7 @@ The details of the spawning process is described in <<app_spawning_and_loading,A
 [[app_spawning_and_loading]]
 == Application spawning and loading
 
-Application processes are spawned from the HelperAgent process. Spawning a process involves a lot of **preparation work**, such as setting up communication channels, setting up the current working directory, environment variables, etc. This preparation work is done by <<spawner_subsystem,a Spawner object>>, together with various support executables.
+Application processes are spawned from the Passenger core process. Spawning a process involves a lot of **preparation work**, such as setting up communication channels, setting up the current working directory, environment variables, etc. This preparation work is done by <<spawner_subsystem,a Spawner object>>, together with various support executables.
 
 When preparation is done, your application's entry point has to be loaded somehow. That loading is done through a language-specific **loader program**. The loader program communicates with the Spawner through the communication channel that was set up earlier, initializes the language-specific environment, sets up a server, and reports back to the Spawner. This communication is done through a certain **protocol**.
 
@@ -274,7 +274,7 @@ The communication channel in question is -- from the viewpoint of the (pre)loade
 
 ==== Loading SpawnPreparer, possibly through bash
 
-Because the HelperAgent is heavily multi-threaded, the child process has been forked by the Spawner link:http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html[may only perform async-signal-safe operations]:
+Because the Passenger core is heavily multi-threaded, the child process has been forked by the Spawner link:http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html[may only perform async-signal-safe operations]:
 
 [quote, The Open Group's POSIX specification, fork() man page]
 "A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls."
@@ -417,7 +417,7 @@ After reporting readiness, the loader can <<loader_main_loop,enter a main loop a
 
 If something goes wrong in any of the stages, the loader can report an error in two ways:
 
- 1. Just write the error message to stdout as you normally do, and abort without printing the `!> Ready` message. The HelperAgent will read everything that the loader has written to stdout, and use it as the error message. This error message is considered to be plain text.
+ 1. Just write the error message to stdout as you normally do, and abort without printing the `!> Ready` message. The Passenger core will read everything that the loader has written to stdout, and use it as the error message. This error message is considered to be plain text.
  2. Abort after printing a special `!> Error` message. The loader can signal that the message is HTML. The RequestHandler will format the error message as HTML.
 
 [[loader_main_loop]]
@@ -434,7 +434,7 @@ If the server was listening on a Unix domain socket file, then the loader doesn'
 
 ==== Stdout and stderr forwarding
 
-All lines that the loader writes to stdout, and that are not prefixed with `!> `, are forwarded by the HelperAgent to its own stdout. Similarly, everything that the loader writes to stderr, whether prefixed with `!> ` or not, is forwarded by the HelperAgent to its own stdout.
+All lines that the loader writes to stdout, and that are not prefixed with `!> `, are forwarded by the Passenger core to its own stdout. Similarly, everything that the loader writes to stderr, whether prefixed with `!> ` or not, is forwarded by the Passenger core to its own stdout.
 
 While the Spawner is still doing its work, it takes care of this forwarding by itself. Once the Spawner is done, it outsources this work to two PipeWatcher objects, each which spawns a background thread for this purpose.
 
@@ -459,7 +459,7 @@ When a spawn command is received, the preloader forks off a child process (which
 [[app_types_registry]]
 === The AppTypes registry
 
-When the web server receives a request, the Phusion Passenger module inside it autodetects the type of application that the request belongs to. It does that by examening the filesystem and checking which one of the startup files exist. For example, if `config.ru` exists, then it assumes that it's a Ruby app. Or if `app.js` exists, then it assumes that it's a Node.js app. The Phusion Passenger module forwards the inferred application type to the HelperAgent.
+When the web server receives a request, the Phusion Passenger module inside it autodetects the type of application that the request belongs to. It does that by examening the filesystem and checking which one of the startup files exist. For example, if `config.ru` exists, then it assumes that it's a Ruby app. Or if `app.js` exists, then it assumes that it's a Node.js app. The Phusion Passenger module forwards the inferred application type to the Passenger core.
 
 Given an application type, the associated loader and preloader can be looked up.
 
@@ -474,7 +474,7 @@ Information about the supported application types, startup files, loaders and pr
 [[instance_state_and_communication]]
 == Instance state and communication
 
-Every time you start Phusion Passenger, you've created a new *instance*. Every instance consists of multiple processes that work together (Watchdog, HelperAgent, LoggingAgent, application processes). All those processes have to be able to communicate with each other. Those processes must also *not* communicate with the processes belonging to other instances. For example, if you start Apache+Passenger *and* Nginx+Passenger, then we don't want the HelperAgent that's started from Apache to use LoggingAgent that's started from Nginx.
+Every time you start Phusion Passenger, you've created a new *instance*. Every instance consists of multiple processes that work together (Watchdog, Passenger core, UstRouter, application processes). All those processes have to be able to communicate with each other. Those processes must also *not* communicate with the processes belonging to other instances. For example, if you start Apache+Passenger *and* Nginx+Passenger, then we don't want the Passenger core that's started from Apache to use UstRouter that's started from Nginx.
 
 Clearly, the processes can't listen on a specific TCP port for communication. Nor can they listen on a fixed Unix domain socket filename.
 

data/doc/ServerOptimizationGuide.html

@@ -566,15 +566,15 @@ PassengerThreadCount 195
 
 <p>In certain situations, using the builtin HTTP engine in Passenger Standalone may yield some performance benefits because it skips a layer of processing.</p>
 
-<p>Passenger normally works by integrating into Nginx or Apache. As described in the <a href="Design%20and%20architecture.html">Design &amp; Architecture</a> document, requests are first handled by Nginx or Apache, and then forwarded to the Passenger core process (the HelperAgent) and the application process. This architecture provides various benefits, such as security benefits (Nginx and Apache's HTTP connection handling routines are thoroughly battle-tested and secure) and feature benefits (e.g. Gzip compression, superb static file handling).</p>
+<p>Passenger normally works by integrating into Nginx or Apache. As described in the <a href="Design%20and%20Architecture.html">Design &amp; Architecture</a> document, requests are first handled by Nginx or Apache, and then forwarded to the Passenger core process (the Passenger core) and the application process. This architecture provides various benefits, such as security benefits (Nginx and Apache's HTTP connection handling routines are thoroughly battle-tested and secure) and feature benefits (e.g. Gzip compression, superb static file handling).</p>
 
 <p>This is even true if you use the Standalone mode. Although it acts standalone, it is implemented under the hood by running Passenger in a builtin Nginx engine.</p>
 
 <p>However, the fact that all requests go through Nginx or Apache means that there is a slight overhead, which can be avoided. This overhead is small (much smaller than typical application and network overhead), and using Nginx or Apache is very useful, but in certain special situations it may be beneficial to skip this layer.</p>
 
 <ul>
-<li>In <strong>microbenchmarks</strong>, the overhead of Nginx and Apache are very noticeable. Removing Nginx and Apache from the setup, and benchmarking against the Passenger HelperAgent directly, will yield much better results.</li>
-<li>In some <strong>multi-server setups</strong>, Nginx and Apache may be redundant. Recall that in typical multi-server setups there is a load balancer which forwards requests to one of the many web servers. Each web server in this setup runs Passenger. But the load balancer is sometimes already responsible for many of the tasks that Nginx and Apache perform, e.g. the secure handling of HTTP connections, buffering, slow client protection or even static file serving. In these cases, removing Nginx and Apache from the web servers and load balancing to the Passenger HelperAgent directly may have a minor improvement on performance.</li>
+<li>In <strong>microbenchmarks</strong>, the overhead of Nginx and Apache are very noticeable. Removing Nginx and Apache from the setup, and benchmarking against the Passenger core directly, will yield much better results.</li>
+<li>In some <strong>multi-server setups</strong>, Nginx and Apache may be redundant. Recall that in typical multi-server setups there is a load balancer which forwards requests to one of the many web servers. Each web server in this setup runs Passenger. But the load balancer is sometimes already responsible for many of the tasks that Nginx and Apache perform, e.g. the secure handling of HTTP connections, buffering, slow client protection or even static file serving. In these cases, removing Nginx and Apache from the web servers and load balancing to the Passenger core directly may have a minor improvement on performance.</li>
 </ul>
 
 

data/doc/ServerOptimizationGuide.txt.md

@@ -360,14 +360,14 @@ Phusion Passenger supports out-of-band garbage collection for Ruby apps. With th
 
 In certain situations, using the builtin HTTP engine in Passenger Standalone may yield some performance benefits because it skips a layer of processing.
 
-Passenger normally works by integrating into Nginx or Apache. As described in the [Design & Architecture](Design%20and%20architecture.html) document, requests are first handled by Nginx or Apache, and then forwarded to the Passenger core process (the HelperAgent) and the application process. This architecture provides various benefits, such as security benefits (Nginx and Apache's HTTP connection handling routines are thoroughly battle-tested and secure) and feature benefits (e.g. Gzip compression, superb static file handling).
+Passenger normally works by integrating into Nginx or Apache. As described in the [Design & Architecture](Design%20and%20Architecture.html) document, requests are first handled by Nginx or Apache, and then forwarded to the Passenger core process (the Passenger core) and the application process. This architecture provides various benefits, such as security benefits (Nginx and Apache's HTTP connection handling routines are thoroughly battle-tested and secure) and feature benefits (e.g. Gzip compression, superb static file handling).
 
 This is even true if you use the Standalone mode. Although it acts standalone, it is implemented under the hood by running Passenger in a builtin Nginx engine.
 
 However, the fact that all requests go through Nginx or Apache means that there is a slight overhead, which can be avoided. This overhead is small (much smaller than typical application and network overhead), and using Nginx or Apache is very useful, but in certain special situations it may be beneficial to skip this layer.
 
- * In **microbenchmarks**, the overhead of Nginx and Apache are very noticeable. Removing Nginx and Apache from the setup, and benchmarking against the Passenger HelperAgent directly, will yield much better results.
- * In some **multi-server setups**, Nginx and Apache may be redundant. Recall that in typical multi-server setups there is a load balancer which forwards requests to one of the many web servers. Each web server in this setup runs Passenger. But the load balancer is sometimes already responsible for many of the tasks that Nginx and Apache perform, e.g. the secure handling of HTTP connections, buffering, slow client protection or even static file serving. In these cases, removing Nginx and Apache from the web servers and load balancing to the Passenger HelperAgent directly may have a minor improvement on performance.
+ * In **microbenchmarks**, the overhead of Nginx and Apache are very noticeable. Removing Nginx and Apache from the setup, and benchmarking against the Passenger core directly, will yield much better results.
+ * In some **multi-server setups**, Nginx and Apache may be redundant. Recall that in typical multi-server setups there is a load balancer which forwards requests to one of the many web servers. Each web server in this setup runs Passenger. But the load balancer is sometimes already responsible for many of the tasks that Nginx and Apache perform, e.g. the secure handling of HTTP connections, buffering, slow client protection or even static file serving. In these cases, removing Nginx and Apache from the web servers and load balancing to the Passenger core directly may have a minor improvement on performance.
 
 Nginx and Apache can be removed by using Passenger's builtin HTTP engine. By using this engine, Passenger will listen directly on a socket for HTTP requests, without using Nginx or Apache.
 

data/doc/Users guide Apache.html

@@ -1441,7 +1441,7 @@ width:100%;
 <td class="tableblock halign-left valign-top"><p class="tableblock">2.6</p></td>
 </tr>
 <tr>
-<td class="tableblock halign-left valign-top"><p class="tableblock">Node.js</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Node.js/io.js</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">0.10</p></td>
 </tr>
 <tr>
@@ -2048,7 +2048,7 @@ kill PID_OF_FLYING_PASSENGER</pre>
 <pre>passenger-memory-stats</pre>
 </div>
 </div>
-<div class="paragraph"><p>You should see the web server processes as well as a number of Phusion Passenger processes (e.g. PassengerWatchdog, PassengerHelperAgent). Congratulations, Phusion Passenger is now installed and running!</p></div>
+<div class="paragraph"><p>You should see the web server processes as well as a number of Phusion Passenger processes (e.g. PassengerAgent watchdog, PassengerAgent core). Congratulations, Phusion Passenger is now installed and running!</p></div>
 <div class="paragraph"><p>If the output is not as expected, then please refer to the <a href="#troubleshooting">Troubleshooting</a> section.</p></div>
 </div>
 <div class="sect2">
@@ -2137,7 +2137,7 @@ configuration file. However, it doesn’t copy any files to outside the Phusion
 <pre>./bin/passenger-memory-stats</pre>
 </div>
 </div>
-<div class="paragraph"><p>You should see the web server processes as well as a number of Phusion Passenger processes (e.g. PassengerWatchdog, PassengerHelperAgent). Congratulations, Phusion Passenger is now installed and running!</p></div>
+<div class="paragraph"><p>You should see the web server processes as well as a number of Phusion Passenger processes (e.g. PassengerAgent watchdog, PassengerAgent core). Congratulations, Phusion Passenger is now installed and running!</p></div>
 <div class="paragraph"><p>If the output is not as expected, then please refer to the <a href="#troubleshooting">Troubleshooting</a> section.</p></div>
 </div>
 <div class="sect2">
@@ -4078,7 +4078,7 @@ In a virtual host configuration block.
 <a href="javascript:void(0)" class="comments empty" title="Add a comment"><span class="count"></span></a><span class="anchor_helper" id="PassengerLoadShellEnvvars"></span><h4 data-comment-topic="passengerloadshellenvvars-on-off--1290yz1" data-anchor="PassengerLoadShellEnvvars">7.4.14. PassengerLoadShellEnvvars &lt;on|off&gt;</h4>
 <div class="paragraph"><p><strong>Introduced in version 4.0.20.</strong></p></div>
 <div class="paragraph"><p>Enables or disables the loading of shell environment variables before spawning the application.</p></div>
-<div class="paragraph"><p>If this option is turned on, and the user’s shell is <span class="monospaced">bash</span>, then applications are loaded by running them with <span class="monospaced">bash -l -c</span>. Otherwise, they are loaded by running them directly from the <span class="monospaced">PassengerHelperAgent</span> process.</p></div>
+<div class="paragraph"><p>If this option is turned on, and the user’s shell is <span class="monospaced">bash</span>, then applications are loaded by running them with <span class="monospaced">bash -l -c</span>. Otherwise, they are loaded by running them directly from the <span class="monospaced">PassengerAgent core</span> process.</p></div>
 <div class="paragraph"><p>This option may occur in the following places:</p></div>
 <div class="ulist"><ul>
 <li>
@@ -4868,7 +4868,7 @@ In <em>.htaccess</em>, if <span class="monospaced">AllowOverride Limits</span> i
 queries <span class="monospaced">/proc</span> to obtain additional memory usage information that’s
 not obtainable through <span class="monospaced">ps</span>. You should ensure that the <span class="monospaced">ps</span> works
 correctly and that the <span class="monospaced">/proc</span> filesystem is accessible by the
-<span class="monospaced">PassengerHelperAgent</span> process.</p></div>
+<span class="monospaced">PassengerAgent core</span> process.</p></div>
 </td>
 </tr></table>
 </div>
@@ -7044,7 +7044,7 @@ Attached process 28303 for app /webapps/foobar.
 <div class="sect3">
 <a href="javascript:void(0)" class="comments empty" title="Add a comment"><span class="count"></span></a><span class="anchor_helper" id="_blocking_and_concurrency"></span><h4 data-comment-topic="blocking-and-concurrency-cxpbyu" data-anchor="_blocking_and_concurrency">10.9.3. Blocking and concurrency</h4>
 <div class="paragraph"><p>Except when otherwise documented, all hooks block in the background. That is, while your hook command is running, Phusion Passenger can still handle web requests, but the background thread which is running your hook will be blocked and won’t be able to perform any further operations. For example, if you wrote a hook script for the <span class="monospaced">attached_process</span> event, then Phusion Passenger won’t be able to attach further processes until your hook script finishes. You should therefore be careful when writing hook scripts.</p></div>
-<div class="paragraph"><p>If you have a bug in your script and it blocks, then you will be able to see that using the command <span class="monospaced">passenger-status --show=backtraces</span> which prints the backtraces of all threads in the Phusion Passenger HelperAgent. Look for the <span class="monospaced">runSingleHookScript</span> function in the backtrace. The following example shows at line 2 that Phusion Passenger is waiting for the hook script <span class="monospaced">/home/phusion/badscript.sh</span>.</p></div>
+<div class="paragraph"><p>If you have a bug in your script and it blocks, then you will be able to see that using the command <span class="monospaced">passenger-status --show=backtraces</span> which prints the backtraces of all threads in the Phusion Passenger core. Look for the <span class="monospaced">runSingleHookScript</span> function in the backtrace. The following example shows at line 2 that Phusion Passenger is waiting for the hook script <span class="monospaced">/home/phusion/badscript.sh</span>.</p></div>
 <div class="listingblock">
 <div class="content monospaced">
 <pre>Thread 'Group process spawner: /home/phusion/webapp.test#default' (0x1062d4000):
@@ -7071,7 +7071,7 @@ Attached process 28303 for app /webapps/foobar.
 </dt>
 <dd>
 <p>
-        Called at the very beginning of Phusion Passenger’s life cycle, during the start of the Watchdog process. The first hook is called before initialization is performed (before the HelperAgent is started). Errors in the hook script cause Phusion Passenger to abort.
+        Called at the very beginning of Phusion Passenger’s life cycle, during the start of the Watchdog process. The first hook is called before initialization is performed (before the Passenger core is started). Errors in the hook script cause Phusion Passenger to abort.
 </p>
 </dd>
 <dt class="hdlist1">
@@ -7578,13 +7578,25 @@ Phusion Passenger’s installer, build system and administration tools are writt
 <p>
 Certain internally used tools, such as the crash handler (which generates a backtrace in case Phusion Passenger crash) and the prespawn script (used to implement
 <a href="#PassengerPreStart">PassengerPreStart</a>)
+are written in Ruby as well.
+</p>
+</li>
+<li>
+<p>
+Ruby web application support is implemented in Ruby.
+</p>
+</li>
+<li>
+<p>
+If you use <a href="#flying_passenger">Flying Passenger</a>, then the Flying Passenger daemon is written in Ruby. The daemon is a small (less than 500 lines of code) and offloads most tasks to the C++ core.
+</p>
+</li>
+<li>
+<p>
+If you use <a href="Users%20guide%20Standalone.html">Phusion Passenger Standalone</a>, then the frontend (the <span class="monospaced">passenger</span> command) is written in Ruby. The frontend is small (less than 1500 lines of code) and offloads most tasks to the C++ core.
 </p>
 </li>
 </ul></div>
-<div class="paragraph"><p>are written in Ruby as well.
- * Ruby web application support is implemented in Ruby.
- * If you use <a href="#flying_passenger">Flying Passenger</a>, then the Flying Passenger daemon is written in Ruby. The daemon is a small (less than 500 lines of code) and offloads most tasks to the C<span class="monospaced"> core.
- * If you use <a href="Users%20guide%20Standalone.html">Phusion Passenger Standalone</a>, then the frontend (the <span class="monospaced">passenger</span> command) is written in Ruby. The frontend is small (less than 1500 lines of code) and offloads most tasks to the C</span> core.</p></div>
 <div class="paragraph"><p>Other than the aforementioned aspects, Phusion Passenger does not use Ruby during normal operation. For example, if you run Python WSGI web applications on Phusion Passenger, then there will be (almost) no Ruby code running on the system.</p></div>
 </div>
 <div class="sect3">
@@ -8380,7 +8392,7 @@ NOTE: Make sure your <span class="monospaced">~/.bashrc</span> is actually inclu
 </div>
 <div class="paragraph"><p>On Debian and Ubuntu, with an Apache installed through apt, Apache environment variables are defined in the file <span class="monospaced">/etc/apache2/envvars</span>. This is a shell script so environment variables must be specified with the shell syntax.</p></div>
 <div class="paragraph"><p>On Red Hat, Fedora, CentOS and ScientificLinux, with an Apache installed through YUM, Apache environment variables are defined in <span class="monospaced">/etc/sysconfig/httpd</span>.</p></div>
-<div class="paragraph"><p>On OS X they are defined in <span class="monospaced">/System/Library/LaunchDaemons/org.apache.httpd.plist</span>, as explained <a href="/System/Library/LaunchDaemons/org.apache.httpd.plist">here on Stack Overflow</a>.</p></div>
+<div class="paragraph"><p>On OS X they are defined in <span class="monospaced">/System/Library/LaunchDaemons/org.apache.httpd.plist</span>, as explained <a href="http://stackoverflow.com/questions/6833939/path-environment-variable-for-apache2-on-mac">here on Stack Overflow</a>.</p></div>
 <div class="paragraph"><p>On other systems, or if you did not install Apache through the system’s package manager, the configuration file for environment variables is specific to the vendor that supplied Apache. There may not even be such a configuration file. You should contact the vendor for support.</p></div>
 </div>
 <div class="sect3">