Ack seems not to be working

[typusomega]

Hi,

I've faced a weird issue concerning the subscriber's ack mechanisms.
It looks like if they would neither work with auto nor with manual acking.

The publisher retrieves an exception after publishing 16384 messages, which is the defualt AckWait-Value.
The weird thing is, that my subscriber obviously receives and (manually) acks messages.

Regards

[ColinSullivan1]

@typusomega , Thank you for raising this issue, we appreciate you using NATS!

Publish acknowledgements are completely decoupled from subscriber acknowledgements. The server sends an acknowledgment to the publisher when the server has persisted the message, independent of what the subscriber may be doing. Subscribers, on the other hand, send acknowledgements to the streaming server to let the server know it received the message, allowing the server to maintain its state of the subscriber for redeliveries, durable subscriptions, etc.

It sounds like the subscribe side is working as expected for you. What exception are you seeing with the publisher?

Thanks,
Colin

[typusomega]

Hi,

thanks for your fast response.

I already assumed that publisher acks and subscriber acks are decoupled. But I think 'Unacked messages on the fly' is the time between publisher and subscriber (not publisher and server)

This is my publisher exception:

Unhandled Exception: STAN.Client.StanException: Timeout occurred.
   at STAN.Client.PublishAck.wait()
   at STAN.Client.Connection.Publish(String subject, Byte[] data)
   at NatsValidation.NatsConnector.Publish(String subject, String message)

Regards

[ColinSullivan1]

@typusomega, Happy to help!

It looks like you are publishing very quickly - the option StanOption.MaxPubAcksInFlight determines how many unacknowledged publish messages can be outstanding from the server when publishing asynchronously, and the default 16k. Your application at that point should block in a publish API until the server returns additional acknowledgements. There is no dependence on the subscriber, in fact the subscriber doesn't even need to be running and can receive the messages later after it starts, based on its options.

The exception you are seeing is caused by the server taking too long to return a publish ack. Could you increase the StanOption.PubAckWait from the default (2000ms) to something larger - perhaps 30,000 ms and see if that clears up your exception?

[typusomega]

Hi,

thanks for your explanation.

This is what I'm doing:

private IStanConnection GetChannel()
{
  if (_connection == null || _connection.NATSConnection.IsClosed())
    _connection = _connectionFactory.CreateConnection(_config.ClusterName, _config.ClientId, _config.StanOptions);
  return _connection;
}

public void PublishRpc(string subject, RpcMessage message)
{
  var watch = new Stopwatch();
  watch.Start();
  GetChannel().Publish(subject, _serializer.ToWire(message));
  watch.Stop();
  Console.WriteLine("Publishing took " + watch.ElapsedMilliseconds);
}

Since Publish() is a synchronous call I assumed it would block until the server's ack was received.

I already changed the timeout and it's working that way, so I'm closing this.

Best regards

[ColinSullivan1]

Great! Glad it is working out for you. Again, thanks for raising the issue!