Collect Received Timestamp in Library

[stefanLeo]

We would to measure the time it takes in our code between the NATS library creating the "message object" and our code being able to consume it.

We are using the pull based client FetchConsumer with a batch size of 500 and at times the ingest rate to the client is higher than the service code can than process the messages, which is fine. We just would like to measure the time a msg resides in the NATS java Library queue before the custom code takes it out.

If this is of interest for you I can prepare a PR adding this small piece of code in a non intrusive way (only measure when configured to).
If yes would there be any requirements to storing or taking this timestamp or would you be fine with "currentTimeMillis" or Sytem.nanoTime?
If there is no interest in having that in the official lib I will work around that on my own.

[scottf]

You could always just add a time header to the message right before you publish it, since it goes right into the queue. There is very little code between calling publish and the message ending up in the queue. I'd rather not add anything else in that sequence, even if it's checking an option and doing nothing except when opted in.
You are welcome to make a PR and I will look at it.

[scottf]

Regarding currentTimeMillis or nanoTime, nanoTime won't work. See https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/lang/System.html#nanoTime()

[stefanLeo]

I was more thinking about the receive direction and measuring the (local) time it takes between NatsConnectionReader calling "deliverMessage" in order to add the message to the internal MessageQueue and the time a 3rd party code calls "nextMessage" on e.g. the FetchConsumer.
So it is not about measuring any cross process time or NATS Server performance. Not even about NATS java library perfromance. It is only thought of as a helper if the 3rd party code is too slow to cope with ingest rate to determine how long a message is waiting to be consumed in the internal MessageQueue of the NATS java library as this may affect ack timers.
Therefore I thought nanotime would also work (as its precision is higher and its only about local delay measurement) as documented in the link you provided.

[scottf]

There is something called the MessageManager. In NatsJetStream there are package level factories that can override the default manager, this was done for testing. You could do the same and override the beforeQueueProcessorImpl which is used to determine if something is put into the queue or not and just use that intercept to touch the message.
JetStreamConsumerTests is where that is done, have a look at that.
If you really want to put together a PR, I will look at it, but this would be low priority for me.

[stefanLeo]

thx for the hint!