Running Aeron¶
Before looking at how to run Aeron, it's worth understanding how it is built at a high level. The four major Aeron components are built as Agrona Agents: the Client Conductor, Driver Conductor, Sender and Receiver. Being Agents means they define their functionality in terms of a duty cycle that is repeatedly invoked, but the thread used to invoke them can be controlled separately.
Running the Media Driver¶
The Media Driver can be run in its own JVM (the usual case) or embedded within an application. There is also a C Media Driver that can be used when running standalone for the best performance.
The Media Driver contains three Agents: the Driver Conductor, Sender and Receiver. Aeron has a threading mode configuration that controls how the Agents are invoked. It can utilise 0, 1, 2 or 3 threads:
- INVOKER mode (0 threads): no threads are created, the Media Driver has to be embedded within an application, which is responsible for invoking the duty cycle of the Agents. Useful for low CPU resource systems
- SHARED mode (1 thread): one thread is created, which uses a CompositeAgent to drive all 3 Agent duty cycles
- SHARED_NETWORK mode (2 threads): one thread is created to run the Driver Conductor and another thread to run a CompositeAgent containing the Sender and Receiver
- DEDICATED mode (3 threads): the default, which creates one thread per Agent. This provides the lowest latency, when enough CPU cores are available
Running the Aeron Client¶
Each Aeron Client has a Client Conductor. It doesn't have many responsibilities, but they include checking it is still connected to the Driver Conductor and processing messages from it, such as a new Image becoming available, or confirmation of a Publication being created.
An Aeron Client is created by creating an instance of the Aeron, class. It is a facade through which an application talks to the Aeron Client API. By default, when an instance of Aeron is created, it creates a thread to run the Client Conductor duty cycle. This can be configured to run in INVOKER mode, which requires the application to invoke the Client Conductor's duty cycle, which does not require the additional thread.