Mention caveat and fix for connections to data-server in golang #66
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dpordomingo
approved these changes
Jan 10, 2019
|
Is this something we should add to the go example analyzer? |
|
Example analyzer doesn't keep an open connection to data server but opens a new one for each event. |
carlosms
reviewed
Jan 10, 2019
README.md
Outdated
| @@ -38,6 +38,8 @@ When DataService is being dialed, you should: | |||
| - turn off [gRPC fail-fast](https://github.com/grpc/grpc/blob/master/doc/wait-for-ready.md) mode if your analyzer creates a connection to DataServer before it was actually started. This way the RPCs are queued until the chanel is ready: | |||
| - go: using `grpc.FailFast(false)` | |||
| ([example](https://github.com/src-d/lookout-gometalint-analyzer/blob/7b4b37fb3109299516fbb43017934d131784f49f/cmd/gometalint-analyzer/main.go#L66)). | |||
| - golang: reset connection backoff to data server on event: | |||
| if you keep connection to data server open you need to reset backoff when analyzer receives new event. Use conn.[ResetConnectBackoff](https://godoc.org/google.golang.org/grpc#ClientConn.ResetConnectBackoff) method in your event handlers. It's needed to avoid broken connection after lookoutd redeployment. In case of a long restart of lookoutd grpc backoff timeout may increase big enough so analyzer wouldn't reconnect before it makes request to data server. | |||
There was a problem hiding this comment.
A suggestion, same text with "DataServer" for consistency with the rest of the doc and more verbosity to make the reason more clear.
Suggested change
| if you keep connection to data server open you need to reset backoff when analyzer receives new event. Use conn.[ResetConnectBackoff](https://godoc.org/google.golang.org/grpc#ClientConn.ResetConnectBackoff) method in your event handlers. It's needed to avoid broken connection after lookoutd redeployment. In case of a long restart of lookoutd grpc backoff timeout may increase big enough so analyzer wouldn't reconnect before it makes request to data server. | |
| golang: reset connection backoff to DataServer on event: | |
| if you keep the connection to DataServer open you need to reset the backoff when your analyzer receives a new event. Use the [`conn.ResetConnectBackoff`](https://godoc.org/google.golang.org/grpc#ClientConn.ResetConnectBackoff) method in your event handlers. It's needed to avoid broken connections after a `lookoutd` redeployment. In case of a long restart of `lookoutd` gRPC server, the backoff timeout may increase so much that the analyzer will not be able to reconnect before it makes the new request to DataServer. |
Signed-off-by: Maxim Sukharev <max@smacker.ru>
carlosms
approved these changes
Jan 11, 2019
|
All of them use a new connection for each request as far as I remember. We don't have any "production-ready" go analyzer which would keep an open connection. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ref: #64