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

Add timeout and metrics on delta chunk sends. #73

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lionell-pack-ttd
Copy link
Contributor

Fixes UID2-2612.
Add timeout to delta chunk send operation.
Add a metric for how long this operation takes so we can reduce the timeout once we have more data.

Add a metric for how long this operation takes so we can reduce the timeout once we have more data.
@@ -85,6 +94,8 @@ public Future<Void> send(OptOutEntry entry) {
}

if (SUCCESS_STATUS_CODES.contains(resp.statusCode())) {
long finishTimeMs = System.currentTimeMillis();
timer.record(finishTimeMs - startTimeMs, TimeUnit.MILLISECONDS);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently only recording successful sends - failures could happen for a range of reasons that might affect the time they take, so having a timer on "any failed request" probably isn't useful.

@@ -42,7 +48,8 @@ public Future<Void> send(BiFunction<URI, HttpMethod, HttpRequest> requestCreator
Promise<Void> promise = Promise.promise();

HttpRequest request = requestCreator.apply(this.uri, this.method);
CompletableFuture<HttpResponse<String>> asyncResponse = this.httpClient.sendAsync(request, HttpResponse.BodyHandlers.ofString());
CompletableFuture<HttpResponse<String>> asyncResponse = this.httpClient.sendAsync(request, HttpResponse.BodyHandlers.ofString())
.orTimeout(this.resultTimeoutMs, TimeUnit.MILLISECONDS);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The timeout. This won't hit the retry logic - the retries only kick in if the overall network request succeeds and the server returns a failure (i.e. the future succeeds with a response indicating failure). This is consistent with that behavior, but maybe we want to think about whether exceptions should also trigger the retry logic.

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.

1 participant