nats-stream nack

[R.I.Pienaar]

hello,

When processing messages from a stream I sometimes have failures in
handling - I do manual acking on messages.

Problems is, if I fail - I cant tell streaming specifically I want to
give up on this message, I have to just wait for ack timeout to happen
which can be quite a while. I keep my max inflight small so not being
able to nack something sometimes cause my consumer to stall with all its
messages sitting in ack wait

Whats the right pattern for doing nacks? I assume this is not in the
protocol for a reason, like maybe you feel its not needed for some other
reason so guidance on what your thoughts are would be good.

--
R.I.Pienaar / www.devco.net / @ripienaar

[Ivan Kozlovic]

R.I.Piennar

If you want to give up on a message, why not ack'ing it?

The reason for using manual ACK is that the application wants the message

to be resent if for some reason it could not process it at a given time.

It is in essence asking the server to resend it later.

Now, if you know that you are not going to be able to process that message,

and you don't want to have to deal with it again, then ack it, so the server

will stop resending it.

Another heavier way would be to stop the subscription and restart at the next

sequence, but this is assuming that you had processed all previous messages.

Hope this helps

Ivan.

[R.I.Pienaar]

On Thu, Oct 12, 2017, at 20:32, Ivan Kozlovic wrote:
> R.I.Piennar
>
> If you want to give up on a message, why not ack'ing it?
> The reason for using manual ACK is that the application wants the message
> to be resent if for some reason it could not process it at a given time.
> It is in essence asking the server to resend it later.
>
> Now, if you know that you are not going to be able to process that
> message, and you don't want to have to deal with it again, then ack it, so the
> server will stop resending it.
>
> Another heavier way would be to stop the subscription and restart at the
> next sequence, but this is assuming that you had processed all previous
> messages.
>

perhaps I was not clear or used 'nack' wrongly - I want to tell the
server I am giving up on this message and it can resend it later -
perhaps to another member of the subscription group.

I specifically want it back later, I just dont want to wait around for
ack_timeout for the next message. Without being able to tell the server
I am not going to be able to manage this message (but dont want to loose
it) I have to wait for ack_timeout to pass

[Ivan Kozlovic]

Sorry I misunderstood.

So yes, there is no way to force the server to redeliver right away (to this

member or any other). Which indeed could cause your client to stall

until the ack wait if you are holding as many as maxInflight messages without

having ack'ing them.

For queue subscriptions, a close of this queue member would force the server to

redeliver its pending messages to other members.

Ivan.