pub trait FetchQueueConfig: 'static + Send + Sync {
fn merge_fetch_contexts(&self, a: u32, b: u32) -> u32;
fn item_retry_delay(&self) -> Duration { ... }
fn source_retry_delay(&self) -> Duration { ... }
}
Expand description
Host-defined details about how the fetch queue should function
Required Methods§
fn merge_fetch_contexts(&self, a: u32, b: u32) -> u32
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§
fn item_retry_delay(&self) -> Duration
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.
fn source_retry_delay(&self) -> Duration
fn source_retry_delay(&self) -> Duration
How long between successive fetches from a particular source, for a particular item? This protects us from wasting resources on a source which may be offline. This will eventually be replaced with an exponential backoff which will be tracked for this source across all items.