Skip to content
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

Set custom http client #67

Merged
merged 11 commits into from
Oct 28, 2019
Merged

Conversation

Bobochka
Copy link
Contributor

@Bobochka Bobochka commented Oct 3, 2019

Hello.

I wish there could be a way to set custom http client. Currently the only way to change http settings is either to change http.DefaultClient or to re-implement transport's Send method. Neither is handy. If you're ok with general direction will add specs and doc comments. Thanks.

@@ -27,6 +28,7 @@ type AsyncTransport struct {
PrintPayloadOnError bool
bodyChannel chan payload
waitGroup sync.WaitGroup
httpClient *http.Client
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, wdyt about extracting duplicated code into BaseTransport struct and embedding it in both transports?

@waltjones
Copy link
Contributor

@Bobochka This looks like a good idea. I'd recommend storing the client in Client, not the transports. Then you don't need to change the args to clientPost and don't need to make changes in the transports.

@Bobochka
Copy link
Contributor Author

Bobochka commented Oct 4, 2019

@waltjones Thanks for the feedback! I might be missing something, but it seems that because of https://github.com/rollbar/rollbar-go/blob/master/client.go#L603 if client will be stored in Client and not Transport, then the client should be a parameter to Send which doesn't look very nice. I was even thinking of changing signature to Send(body map[string]interface{}, httpClient ...*http.Client) error not to break custom Transport implementations, but that's quite ugly as well. WDYT? Thanks.

@waltjones
Copy link
Contributor

@Bobochka I think I looked too quickly and thought it was func (c *Client) clientPost(...) and the transport already had the reference. You are correct.

clientPost is only used by the transports and doesn't need anything from Client. Maybe there should be a BaseTransport as you suggest, and clientPost should should go there. (Renamed to post or Post I would think.) What do you think?

}

io.Copy(ioutil.Discard, resp.Body)
resp.Body.Close()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@waltjones note the change in 2 lines above. Body draining allows connection reuse, currently it's reconnecting every request.

@Bobochka
Copy link
Contributor Author

Bobochka commented Oct 4, 2019

@waltjones changed accordingly, take a look please. Specs and comments to go.

}

// SetHTTPClient sets custom http client. http.DefaultClient is used by default
func (t *baseTransport) SetHTTPClient(c *http.Client) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure this needs to be protected by a mutex otherwise it's a race condition once the transport is actively sending things to rollbar.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS: I believe that is also true of all of the above methods as well.

Copy link
Contributor Author

@Bobochka Bobochka Oct 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, technically you're right, but in reality nothing bad can happen - pointers aren't spread through multiple machine words (at least on most architectures), meaning it's not possible that broken pointer will be read by transport if it's already running.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seem to be a variety of potential concurrency issues. I'd rather address them together, and not burden this PR with it.

@Bobochka
Copy link
Contributor Author

@waltjones Please let me know if other changes needed. Thanks.

@waltjones
Copy link
Contributor

@Bobochka I expect to be able to get to it this week. Thank you!

@waltjones
Copy link
Contributor

@Bobochka It looks like the default http client doesn't get initialized. This condition can be exercised by running tests with a live token:
TOKEN=POST_SERVER_ITEM_ACCESS_TOKEN go test

For the lint error, it looks like you could just swap the return values. Let me know if there's any reason not to do that.

Overall everything else is looking good. I'd like to do more testing once the default client issue is resolved.

@Bobochka
Copy link
Contributor Author

@waltjones sorry, my bad. Fixed both issues.

@waltjones
Copy link
Contributor

@Bobochka thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants