Trait holochain::prelude::kitsune_p2p::dependencies::kitsune_p2p_fetch::FetchPoolConfig

source · 
pub trait FetchPoolConfig: 'static + Send + Sync {
    // Required method
    fn merge_fetch_contexts(&self, a: u32, b: u32) -> u32;

    // Provided methods
    fn item_retry_delay(&self) -> Duration { ... }
    fn source_retry_delay(&self) -> Duration { ... }
    fn fetch_batch_size(&self) -> usize { ... }
    fn source_unavailable_timeout_threshold(&self) -> usize { ... }
}
Expand description

Host-defined details about how the fetch queue should function

Required Methods§

source

fn merge_fetch_contexts(&self, a: u32, b: u32) -> u32

When a fetch key is added twice, this determines how the two different contexts get reconciled.

Provided Methods§

source

fn item_retry_delay(&self) -> Duration

How long between successive item fetches, regardless of source? This gives a source a fair chance to respond before proceeding with a different source.

The most conservative setting for this is 2 * tuning_params.implicit_timeout, since that is the maximum amount of time a successful response can take. Lower values will give up early and may result in duplicate data sent if the response takes a long time to come back.

source

fn source_retry_delay(&self) -> Duration

How long to put a source on a backoff if it fails to respond to a fetch. This is an initial value for a backoff on the source and will be increased if the source remains unresponsive.

With the default settings of 30s for this delay and 8 retries, the total retry period is around 20 minutes (with jitter) so that the time we keep sources in the pool is close to the default value for the TTL on agent info. This means if an agent goes offline then they should be removed from the fetch pool in a similar amount of time to other communication with them ceasing.

source

fn fetch_batch_size(&self) -> usize

How many items should be returned for fetching per call to FetchPool::get_items_to_fetch.

source

fn source_unavailable_timeout_threshold(&self) -> usize

The number of times a source can fail to respond in time before it is put on a backoff.

This is a total number of timeouts so if a source is unreliable over time then it will be put on a backoff even if it is currently responding. If the source responds after its timeout period then this counter will be reset and the source will be considered available again after a single backoff period.

The reasoning behind this parameter is that we want to limit the amount of resources we sink into an unresponsive source, as well as limiting the load on the source itself, who may be unresponsive because they’re already struggling with too much load.

Implementors§