push
based where JetStream will deliver the messages as fast as possible (while adhering to the rate limit policy) to a subject of your choice or pull
to have control by asking the server for messages. The choice of what kind of consumer to use depends on the use-case but typically in the case of a client application that needs to get their own individual replay of messages from a stream you would use an 'ordered push consumer', while in the case of scaling horizontally the processing of messages from a stream you would use a 'pull consumer'.ReplayPolicy
. A ReplayInstant
Consumer will receive all messages as fast as possible while a ReplayOriginal
Consumer will receive messages at the rate they were received, which is great for replaying production traffic in staging.ORDERS.processed
. The Stream consumes ORDERS.*
and this allows you to receive just what you need. The final Consumer receives all messages in a push
fashion.StreamSeq
), specific time (StartTime
), all (DeliverAll
) or last (DeliverLast
). This is the starting point and from there, they all behave the same - delivering all of the following messages with optional Acknowledgement.AckExplicit
- the only supported mode for pull-based Consumers - meaning every message requires a distinct acknowledgement. But for push-based Consumers, you can set AckNone
that does not require any acknowledgement, or AckAll
which quite interestingly allows you to acknowledge a specific message, like message 100
, which will also acknowledge messages 1
through 99
. The AckAll
mode can be a great performance boost.MaxDeliver
setting allow you to set an upper bound to how many times a message may be delivered.SampleFrequency
which is a percentage of messages for which the system should sample and create events. These events will include delivery counts and ack waits.IMPORTANTThe server may consider an ack arriving out of the window. If a first process fails to ack within the window it's entirely possible, for instance in queue situation, that the message has been redelivered to another consumer. Since this will technically restart the window, the ack from the first consumer will be considered.
DeliverPolicy
and it's options are as follows:OptStartSeq
, the sequence number to start on. It will receive the closest available message moving forward in the sequence should the message specified have been removed based on the stream limit policy.OptStartTime
, the time in the stream to start at. It will receive the closest available message on or after that time.DeliverAll
, DeliverByStartSequence
or DeliverByStartTime
since those deliver policies begin reading the stream at a position other than the end. If the policy is ReplayOriginal
, the messages in the stream will be pushed to the client at the same rate that they were originally received, simulating the original timing of messages. If the policy is ReplayInstant
(the default), the messages will be pushed to the client as fast as possible while adhering to the Ack Policy, Max Ack Pending and the client's ability to consume those messages.30
and 30%
as valid values.