Struct nats::jetstream::ConsumerConfig [−][src]
pub struct ConsumerConfig {}Show fields
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
[src]
impl Clone for ConsumerConfig
[src]fn clone(&self) -> ConsumerConfig
[src]
pub fn clone_from(&mut self, source: &Self)
1.0.0[src]
impl Default for ConsumerConfig
[src]
impl Default for ConsumerConfig
[src]fn default() -> ConsumerConfig
[src]
impl<'de> Deserialize<'de> for ConsumerConfig
[src]
impl<'de> Deserialize<'de> for ConsumerConfig
[src]fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error> where
__D: Deserializer<'de>,
[src]
__D: Deserializer<'de>,
impl From<&'_ ConsumerConfig> for ConsumerConfig
[src]
impl From<&'_ ConsumerConfig> for ConsumerConfig
[src]fn from(cc: &ConsumerConfig) -> ConsumerConfig
[src]
impl From<&'_ str> for ConsumerConfig
[src]
impl From<&'_ str> for ConsumerConfig
[src]fn from(s: &str) -> ConsumerConfig
[src]
impl Serialize for ConsumerConfig
[src]
impl Serialize for ConsumerConfig
[src]Auto Trait Implementations
impl RefUnwindSafe for ConsumerConfig
impl RefUnwindSafe for ConsumerConfig
impl Send for ConsumerConfig
impl Send for ConsumerConfig
impl Sync for ConsumerConfig
impl Sync for ConsumerConfig
impl Unpin for ConsumerConfig
impl Unpin for ConsumerConfig
impl UnwindSafe for ConsumerConfig
impl UnwindSafe for ConsumerConfig
Blanket Implementations
impl<T> DeserializeOwned for T where
T: for<'de> Deserialize<'de>,
[src]
impl<T> DeserializeOwned for T where
T: for<'de> Deserialize<'de>,
[src]impl<T> Same<T> for T
impl<T> Same<T> for T
type Output = T
Should always be Self
impl<V, T> VZip<V> for T where
V: MultiLane<T>,
impl<V, T> VZip<V> for T where
V: MultiLane<T>,