-
Notifications
You must be signed in to change notification settings - Fork 5
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
RHPv4 Client #17
RHPv4 Client #17
Conversation
74ba279
to
09ab824
Compare
rhp/v4/client.go
Outdated
// dial a stream with a sane deadline | ||
c.mu.Lock() | ||
s := c.mux.DialStream() | ||
c.mu.Unlock() |
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.
why lock here?
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.
Because we swap out the mux
sometimes
rhp/v4/client.go
Outdated
} else if err := c.resetTransport(ctx); err != nil { | ||
// failed to reset transport | ||
c.mu.Unlock() | ||
return fmt.Errorf("%v: %w", err, errRPC) |
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.
I expect the second error is unlikely to be helpful to the caller. I would just return errRPC
here
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.
I think it's useful to know to determine whether we are not handling resetting the connection correctly or if resetting the connection actually fails. e.g. if the error is "connection refused" we might want to drop the mux completely.
Closes #8