pushbased where JetStream will deliver the messages as fast as possible (while adhering to the rate limit policy) to a subject of your choice or
pullto 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'.
ReplayInstantConsumer will receive all messages as fast as possible while a
ReplayOriginalConsumer 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
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
AckNonethat does not require any acknowledgement, or
AckAllwhich quite interestingly allows you to acknowledge a specific message, like message
100, which will also acknowledge messages
AckAllmode can be a great performance boost.
MaxDeliversetting allow you to set an upper bound to how many times a message may be delivered.
SampleFrequencywhich 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.
DeliverPolicyand 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.
DeliverByStartTimesince 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%as valid values.