Module split

Splits a single [Service] implementing all of ABCI into four cloneable component services, each implementing one category of ABCI requests.

The component services share access to the main service via message-passing over buffered channels. This means that the component services can be cloned to provide shared access to the ABCI application, which processes requests sequentially with the following prioritization:

1. [ConsensusRequest]s sent to the Consensus service;
2. [MempoolRequest]s sent to the Mempool service;
3. [SnapshotRequest]s sent to the Snapshot service;
4. [InfoRequest]s sent to the Info service.

The ABCI service can execute these requests synchronously, in Service::call, or asynchronously, by immediately returning a future that will be executed on the caller’s task. Or, it can split the difference and perform some amount of synchronous work and defer the rest to be performed asynchronously.

Because each category of requests is handled by a different service, request behavior can be customized on a per-category basis using Tower Layers. For instance, load-shedding can be added to [InfoRequest]s but not [ConsensusRequest]s, or different categories can have different timeout policies, or different types of instrumentation.

Modules

• futures
  Futures types.

Structs

• Consensus
  Forwards consensus requests to a shared backing service.
• Info
  Forwards info requests to a shared backing service.
• Mempool
  Forwards mempool requests to a shared backing service.
• Snapshot
  Forwards snapshot requests to a shared backing service.

Functions

• service
  Splits a single service implementing all of ABCI into four cloneable component services, each implementing one category of ABCI requests. See the module documentation for details.