Running Engines in Multiplexed Mode

On machines with multi-core processors, GridServer, by default, runs an Engine instance in its own process per logical CPU. While this enables each process to work on different Services, it also means each process runs in its own JVM, and requires its own set of application data. This can cause unwanted overhead when running the same Service across many CPU cores.

To address this issue, you can run Engines in multiplexed mode, meaning that all Engine instances run in a single process. This enables all Engine instances on that machine to share the same set of application data, and multiplex their communication with the Broker.

Multiplexed Engines appear as individual Engines in the GridServer Administration Tool and by the Admin API. Each multiplexed Engine has its own log, work, temp, and data directories. They produce the same output to the reporting database.

You can’t mix single-process Engine instances and multiplexed Engines on the same machine. For example, on an eight-core machine, you can’t have two processes with four multiplexed Engines each; you can only have eight multiplexed Engines in one process.

Multiplexed Engines have the following differences with Engines running in their own processes:

All Engines are logged in to the same Broker at any given time. This is enforced by the balancer.
All Engines work on the same Service session at any given time. This is enforced by the Scheduler
All Engines reside in the same classloader, which means they can all share the same set of Service Session data.
They share the same initialization data and Service object. The Service init method is only called once, and all updates are synchronized across all Engines.
If one Engine has to log off, all Engines in the process are also logged off with the same reason.
Incremental scheduling is not supported.
Autopack is not supported.
The Service implementation must be threadsafe. See the GridServer Developer’s Guide for more information about multiplexed mode development considerations.
Running more than one task from a recursive Service is not supported.
All multiplexed Engines share one set of properties. For example, getting the instance property always reports instance 0, regardless of the Engine instance.

When using multiplexed Engines, Engine resources are shared. The first Engine does all library loading, and this Engine is the first to start work. This also means that Engine Hooks are only loaded once, as hooks are loaded when Grid Libraries are loaded.

When using GridCache, there is one cache per process, and all communication is handled by Engine instance 0.