Struct nats::jetstream::ConsumerConfig

pub struct ConsumerConfig {
    pub deliver_subject: Option<String>,
    pub durable_name: Option<String>,
    pub deliver_policy: DeliverPolicy,
    pub opt_start_seq: Option<i64>,
    pub opt_start_time: Option<DateTime>,
    pub ack_policy: AckPolicy,
    pub ack_wait: Option<isize>,
    pub max_deliver: Option<i64>,
    pub filter_subject: Option<String>,
    pub replay_policy: ReplayPolicy,
    pub rate_limit: Option<i64>,
    pub sample_frequency: Option<u8>,
    pub max_waiting: Option<i64>,
    pub max_ack_pending: Option<i64>,
}

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. Acknowledgement 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 acknowledgement 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.

deliver_policy: DeliverPolicy

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

opt_start_seq: Option<i64>

Used in combination with DeliverPolicy::ByStartSeq to only select messages arriving after this sequence number.

opt_start_time: Option<DateTime>

Used in combination with DeliverPolicy::ByStartTime to only select messages arriving after this time.

ack_policy: AckPolicy

How messages should be acknowledged

ack_wait: Option<isize>

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

max_deliver: Option<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: Option<String>

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

replay_policy: ReplayPolicy

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

rate_limit: Option<i64>

The rate of message delivery in bits per second

sample_frequency: Option<u8>

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

max_waiting: Option<i64>

The maximum number of waiting consumers.

max_ack_pending: Option<i64>

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

Trait Implementations

impl Clone for ConsumerConfig

fn clone(&self) -> ConsumerConfig

Returns a copy of the value.

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

Performs copy-assignment from source.

impl Debug for ConsumerConfig

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

Formats the value using the given formatter.

impl Default for ConsumerConfig

fn default() -> ConsumerConfig

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for ConsumerConfig

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error> where
    __D: Deserializer<'de>, 

Deserialize this value from the given Serde deserializer.

impl From<&'_ ConsumerConfig> for ConsumerConfig

fn from(cc: &ConsumerConfig) -> ConsumerConfig

Performs the conversion.

impl From<&'_ str> for ConsumerConfig

fn from(s: &str) -> ConsumerConfig

Performs the conversion.

impl Serialize for ConsumerConfig

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

Serialize this value into the given Serde serializer.