IoActor: basic concepts

• Word count: 225

Actor Hierarchy

IO subsystem consists of the following actors.

All messages are sent to IoActorProxy, which then routes them either to IoActor or IoPromiseProxyActor based on whether the message contains a Promise. IoPromiseProxyActor receives a message with Promise, forwards message to the IoActor, and once response from IoActor comes back, completes the promise.

IoActor has back-pressure (always enabled) and throttling (configurable) features implemented in order to prevent overflowing the incoming messages queue.

Message types and processing logic

IoActor accepts messages of base type IoCommand[T] with or without clientContext (which is a Promise, which will be passed through, back to the IoPromiseProxyActor in the end)

Message processing logic is implemented using Akka Stream API and can be represented with the following graph:

There are 2 message processing flows:
1. "GCS batch flow" to process messages, which are subtypes of GcsBatchIoCommand
1. "Default flow" for all other subtypes of IoCommand

Both "GCS batch flow" and "Default flow" allow to configure desired parallelism level, which can be done during IoActor's creation using gcsParallelism and nioParallelism parameters respectively. The particular implementation logic for each base IO command is encapsulated inside ParallelGcsBatchFlow and NioFlow classes.

The final IoResult is sent both to the "reply sink" which is responsible for sending result to the original sender, and "instrumentation sink", which is responsible for sending InstrumentationServiceMessage to the ServiceRegistryActor