Replies: 4 comments 1 reply
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding currentTimeMillis or nanoTime, nanoTime won't work. See https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/lang/System.html#nanoTime() |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
thx for the hint! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions