Wire up sent nonces#31
Conversation
By adding new, more granular server event types, event handlers now have much more visibility into what the server is doing. Specifically, it can now track pending nonces and in-flight requests. Similarly, because the `RequestReceived` fires when the request is received and `RequestProcessed` fires when the request is *processed*, the two events can be used to track whether the ResourceLocator is hanging.
| // If the request is an ACK or a NACK, it will include a nonce, which should correspond to a nonce | ||
| // listed in a previously emitted [ResponseSent] event. | ||
| Nonce string |
There was a problem hiding this comment.
so, do we plan to detect ResponseSent events that have no ACK/NACK received after a while? which seems to be a straightforward metric to show client side issues.
There was a problem hiding this comment.
Yes, exactly. You will see what this looks like when it's implemented in the observer
| NACKsReceived atomic.Int64 | ||
| ACKsReceived atomic.Int64 | ||
| RequestsReceived atomic.Int64 | ||
| RequestsProcessed atomic.Int64 |
There was a problem hiding this comment.
try to understand the current expectation, is it right to expect that in every min, the RequestsReceived = RequestsProcessed = ACKsReceived + NACKsReceived?
There was a problem hiding this comment.
Not quite as not all requests are ACK/NACK, they could be new resource subscriptions.
It's more like len(Nonces) == NACKsReceived + ACKsReceived. For sure the state should eventually converge to RequestsReceived == RequestsProcessed. Finally, RequestsReceived >= NACKsReceived + ACKsReceived
2 participants
By adding new, more granular server event types, event handlers now have much more visibility into what the server is doing. Specifically, it can now track pending nonces and in-flight requests. Similarly, because the
RequestReceivedfires when the request is received andRequestProcessedfires when the request is processed, the two events can be used to track whether the ResourceLocator is hanging.