Why are push consumers not implemented?

[c3mb0]

It's nice that the entire pull consumer flow tries to "help" the user with load balancing, but the lack of knobs to dial when it comes to customizing the throttling behavior limits the utility of this approach. The project documentation states that if you do not want implicit flow control, you should be using a push consumer. However, the Jetstream package (the standalone, new one) does not have a push consumer and using Jetstream APIs through NATS does not feel right because of the deprecation warning.

What is the correct way of implementing a push consumer? Is it safe to rely on legacy Jetstream API through NATS? Is it maintained? Will it ever be sunset?

My use case involves reading as many things I can for 10 seconds from a stream, create a big batch of something, then send it somewhere. Since this data is important and I cannot afford to lose it, I only ACK the messages after the batch is delivered. The pull consumer flow deems all consumers of this stream incompetent and severly throttles message delivery since it thinks consumers are in some sort of trouble, but this implicit behavior is the exact opposite of what I need. The bigger batches I can make, the more efficient my system is, but since Jetstream thinks the more ack_pending messages, the more throttling needs to be applied, I'm left with an ever growing number of pending messages.

For reference, I've tried the same workload with a "no ack required" stream and it increased the pull consumer throughput by more than 10x.

[Jarema]

Pull consumers retrieve messages in two main ways:
1. Fetch: Requests a specific batch of messages, delivers them, and stops.
2. Consume: Optimizes fetching for continuous delivery, similar to Push Consumers, with tighter flow control (fewer messages/acks waiting in the buffer).

Switching to Push Consumers wouldn’t solve the issue, as max ack pending could still increase.

You might consider using FetchNoWait, which retrieves messages based on limits (number, time, bytes). Set a high message limit and a 10-second fetch expiration to process messages without growing max ack pending before old messages are handled. The tradeoff is a brief pause between fetches, reducing throughput.
If you need sustained performance, Consume works similarly to Push Consumers.

As for the API, Consume has consolidated features from both Push and Pull consumers. While we encourage users to adopt the new API, we’re not deprecating the old one. Some new features (like Consumer Overflow, Priority Groups, and Pinning) will not be ported to the old API, but those anyway work only with Pull Consumers.

[jnmoyne]

Max acks pending is a "one to many" kind of flow control and it applies to both push and pull consumers. If you have a number of client applications fetching batches of messages it still applies so set a max acks pending value that greater than fetch batch size multiplied by the number of clients using those fetches or some of those fetches will not get full batch sizes.

To get messages quickly from a stream also consider using an "ordered consumer" which although not using explicit acks is still ensuring reliable (and ordered) delivery of the messages.