Allow AckAll for pull-based consumers#1063
Conversation
If you are the only client pulling on a given consumer, the efficiency gains of fetching batches is largely lost if you have to acknowledge every message you received individually. It would seem intuitive to be able to acknowledge only the most recent message in the batch instead.
|
On horizontally scaled deployments AckAll would ack messages that are in flight or being processed by different consumers. |
|
@aricart same as push+qsubs which we do support. |
@ripienaar Then I think we should not, meaning we should reject an AckAll for a QueueSubscribe() because indeed there may be more than one member and I think it is bad that one member acks messages from other members. |
|
@kozlovic since 8 months the server allows this - agree its risky and probably a bad idea. |
|
Indeed, seems like the server all since this PR: nats-io/nats-server#2776, so I guess restriction should be removed in client libraries too... yes, I think it is a bad idea. |
|
I can't really comment on the queue subscriptions as not using those, but in the case of one pull subscriber per consumer (as is the pattern that we are using in our application here), Have done quite a bit of testing with this PR and seems to work fine, although wondering if there might be some sensible place to put a comment warning about the potential for multiple clients to tread on each other. |
|
@ripienaar @kozlovic While we are at it, I think we also have the restriction that pull consumers must ack, but wondering if we should allow AckNone - this would allow other scenarios like ordered pull consumer etc. |
|
For the moment, server would not allow that. |
|
AckAll was put in to support emulated push in clients with efficient ephemeral pull consumers under covers. |
kozlovic
left a comment
kozlovic
left a comment
There was a problem hiding this comment.
LGTM. Since the server accepts it, I guess there is no reason to prevent the user to using this ack mode for pull consumers...
6 participants
If you are the only client pulling on a given consumer, the efficiency gains of fetching in batches is largely lost if you have to acknowledge every message you received individually afterwards.
It would seem intuitive to be able to acknowledge only the most recent message in the batch instead and to have that do the right thing.