-
Notifications
You must be signed in to change notification settings - Fork 962
Client Concurrency Model
When clients interact with Aeron it is worth being aware of the concurrency model to know what is safe and what is not safe to be used across threads or processes.
Aeron clients communicate with media driver via the command and control (C'n'C) file which is memory mapped. The media driver can run in or out of process as required. An out of process driver is isolated and can be shared by many clients. Each media driver can have many clients which can concurrently interact. Clients send commands to the driver and the driver will broadcast back events. A bi-directional heart-beating protocol is used between the driver and clients to track each others presence.
Within a process the Aeron client is thread safe and can be shared between threads to manage the life-cycles of publications and subscriptions. It is good practice to have one Aeron client per process but this is not a hard requirement.
Aeron Publications are thread safe within and across processes. A Publication object can be used concurrently from many threads. When separate processes add the same Publication (channel and stream id) then they will map to the same underlying memory-mapped file and can be safely used concurrently. Messages offered to the same publication will be serialised. Publications with a different channel and stream id are completely independent from each other and operate in parallel.
ExclusivePublications can be created for exclusive use by a single thread, they are not thread safe. These exclusive publications can co-exist with other publications of the same channel and stream identifiers but get another session id. Exclusive publications enjoy the benefits of the single writer principle and can benefit from greater throughput, especially in burst scenarios for small messages.
Exclusive publications can additionally provide control of the header when used with the ExclusiveBufferClaim. It is also possible to set the channel URI params for init-term-id, term-id, and term-offset which can be useful in replay scenarios. These params combined with mtu and term-length provide for replay control.
Subscriptions are not thread safe. A Subscription is a aggregate over a set of Images from different sources for the same channel and stream identifier. Each subscribing thread must create its own Subscription and poll for updates. Received messages will be delivered to all subscribers in a similar fashion to how multicast packets are received. Subscriptions to the same channel and stream id in different processes will all receive the same messages from the media driver they are connected to. Subscribers all receive the messages in parallel without additional copies.
When subscriptions join a stream they will receive messages starting from the position reached by an existing stream when they joined, each stream appears as an Image of the source Publication. They do not receive messages which have been received by other subscribers previous to the position at which they joined. If a Subscription is closed and then reopen, it will be rejoining the stream and will miss the messages contain in the stream between the old subscription closing and the new one being added.