-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: report method name in WS metrics #29
base: main
Are you sure you want to change the base?
Conversation
7e1cd82
to
e790296
Compare
Hi Mkykadir, Thanks for the contribution! Its a clever solution, however I am concerned about a race condition occurring with concurrent map access w.reqIdToMethod if the proxyd was under heavy ws traffic. I'm curious if you would be able to find a solution that can avoid this? Also please include test cases if possible |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the PRs current state with concurrent map access, I believe these concerns must be addressed before merging
@jelias2 nice catches actually I missed a crucial point as well:
|
454c87f
to
d745088
Compare
d745088
to
64f854c
Compare
@@ -0,0 +1,56 @@ | |||
package proxyd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some tests for this struct to validate concurrency would nice
res, err := w.parseBackendMsg(msg) | ||
if res != nil { | ||
if value, has := idToMethod.GetAndRemove(string(res.ID)); has { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will res.ID be unique? Typically is determined by the request ID with in the rpc, I don't believe its unique among many requests?
Description
Access method name in WS context so metrics can be reported with method name