Struct async_nats::jetstream::consumer::Config

pub struct Config {

    pub deliver_subject: Option<String>,
    pub durable_name: Option<String>,
    pub name: Option<String>,
    pub description: Option<String>,
    pub deliver_group: Option<String>,
    pub deliver_policy: DeliverPolicy,
    pub ack_policy: AckPolicy,
    pub ack_wait: Duration,
    pub max_deliver: i64,
    pub filter_subject: String,
    pub filter_subjects: Vec<String>,
    pub replay_policy: ReplayPolicy,
    pub rate_limit: u64,
    pub sample_frequency: u8,
    pub max_waiting: i64,
    pub max_ack_pending: i64,
    pub headers_only: bool,
    pub flow_control: bool,
    pub idle_heartbeat: Duration,
    pub max_batch: i64,
    pub max_bytes: i64,
    pub max_expires: Duration,
    pub inactive_threshold: Duration,
    pub num_replicas: usize,
    pub memory_storage: bool,
    pub metadata: HashMap<String, String>,
    pub backoff: Vec<Duration>,
}

Configuration for consumers. From a high level, the durable_name and deliver_subject fields have a particularly strong influence on the consumer’s overall behavior.

Fields

deliver_subject: Option<String>

Setting deliver_subject to Some(...) will cause this consumer to be “push-based”. This is analogous in some ways to a normal NATS subscription (rather than a queue subscriber) in that the consumer will receive all messages published to the stream that the consumer is interested in. Acknowledgment policies such as AckPolicy::None and AckPolicy::All may be enabled for such push-based consumers, which reduce the amount of effort spent tracking delivery. Combining AckPolicy::All with Consumer::process_batch enables particularly nice throughput optimizations.

Setting deliver_subject to None will cause this consumer to be “pull-based”, and will require explicit acknowledgment of each message. This is analogous in some ways to a normal NATS queue subscriber, where a message will be delivered to a single subscriber. Pull-based consumers are intended to be used for workloads where it is desirable to have a single process receive a message. The only valid ack_policy for pull-based consumers is the default of AckPolicy::Explicit, which acknowledges each processed message individually. Pull-based consumers may be a good choice for work queue-like workloads where you want messages to be handled by a single consumer process. Note that it is possible to deliver a message to multiple consumers if the consumer crashes or is slow to acknowledge the delivered message. This is a fundamental behavior present in all distributed systems that attempt redelivery when a consumer fails to acknowledge a message. This is known as “at least once” message processing. To achieve “exactly once” semantics, it is necessary to implement idempotent semantics in any system that is written to as a result of processing a message.

durable_name: Option<String>

Setting durable_name to Some(...) will cause this consumer to be “durable”. This may be a good choice for workloads that benefit from the JetStream server or cluster remembering the progress of consumers for fault tolerance purposes. If a consumer crashes, the JetStream server or cluster will remember which messages the consumer acknowledged. When the consumer recovers, this information will allow the consumer to resume processing where it left off. If you’re unsure, set this to Some(...).

Setting durable_name to None will cause this consumer to be “ephemeral”. This may be a good choice for workloads where you don’t need the JetStream server to remember the consumer’s progress in the case of a crash, such as certain “high churn” workloads or workloads where a crashed instance is not required to recover.

name: Option<String>

A name of the consumer. Can be specified for both durable and ephemeral consumers.

description: Option<String>

A short description of the purpose of this consumer.

deliver_group: Option<String>

Deliver group to use.

deliver_policy: DeliverPolicy

Allows for a variety of options that determine how this consumer will receive messages

ack_policy: AckPolicy

How messages should be acknowledged

ack_wait: Duration

How long to allow messages to remain un-acknowledged before attempting redelivery

max_deliver: i64

Maximum number of times a specific message will be delivered. Use this to avoid poison pill messages that repeatedly crash your consumer processes forever.

filter_subject: String

When consuming from a Stream with many subjects, or wildcards, this selects only specific incoming subjects. Supports wildcards.

filter_subjects: Vec<String>

Fulfills the same role as Config::filter_subject, but allows filtering by many subjects.

replay_policy: ReplayPolicy

Whether messages are sent as quickly as possible or at the rate of receipt

rate_limit: u64

The rate of message delivery in bits per second

sample_frequency: u8

What percentage of acknowledgments should be samples for observability, 0-100

max_waiting: i64

The maximum number of waiting consumers.

max_ack_pending: i64

The maximum number of unacknowledged messages that may be in-flight before pausing sending additional messages to this consumer.

headers_only: bool

Only deliver headers without payloads.

flow_control: bool

Enable flow control messages

idle_heartbeat: Duration

Enable idle heartbeat messages

max_batch: i64

Maximum size of a request batch

max_bytes: i64

Maximum size of a request max_bytes

max_expires: Duration

Maximum value for request expiration

inactive_threshold: Duration

Threshold for ephemeral consumer inactivity

num_replicas: usize

Number of consumer replicas

memory_storage: bool

Force consumer to use memory storage.

metadata: HashMap<String, String>

Additional consumer metadata.

backoff: Vec<Duration>

Custom backoff for missed acknowledgments.

Trait Implementations

impl Clone for Config

fn clone(&self) -> Config

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Config

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for Config

fn default() -> Config

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for Config

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl From<&Config> for Config

fn from(cc: &Config) -> Config

Converts to this type from the input type.

impl From<&str> for Config

fn from(s: &str) -> Config

Converts to this type from the input type.

impl FromConsumer for Config

fn try_from_consumer_config(config: Config) -> Result<Self, Error>

where Self: Sized,

impl IntoConsumerConfig for &Config

fn into_consumer_config(self) -> Config

impl IntoConsumerConfig for Config

fn into_consumer_config(self) -> Config

impl PartialEq for Config

fn eq(&self, other: &Config) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for Config

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl Eq for Config

impl StructuralPartialEq for Config