NEW
and DISPATCH
Consumers are pull-based, meaning the services consuming data from them have to ask the system for the next available message. This means you can easily scale your services up by adding more workers and the messages will get spread across the workers based on their availability.NEW
one:--sample
options on the CLI as this is not prompted for at present, everything else is prompted. The help in the CLI explains each:ORDERS.received
. Remember the Stream subscribes to ORDERS.*
, this lets us select a subset of messages from the Stream.DISPATCH
Consumer:$ nats con info ORDERS DISPATCH -j | jq .config
:MONITOR
Consumer is push-based, has no ack and will only get new messages and is not sampled:$ nats con info ORDERS MONITOR -j | jq .config
:State
section will be shown later when discussing the ack models in depth.Request()
feature, but the nats
utility has a helper:nats
:--no-ack
.Request()
to $JS.API.CONSUMER.MSG.NEXT.ORDERS.DISPATCH
:nats req
cannot ack, but in your code you'd respond to the received message with a nil payload as an Ack to JetStream.MONITOR
Consumer we have no Acknowledgement.ORDERS.processed
this helps you distinguish what you're seeing in a Stream covering a wildcard, or multiple subjects, subject space.