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 default client request timeout #362

Merged
merged 1 commit into from
Mar 16, 2023
Merged

Add default client request timeout #362

merged 1 commit into from
Mar 16, 2023

Conversation

ArtDu
Copy link
Contributor

@ArtDu ArtDu commented Feb 27, 2023

@ akudiyar changed the behaviour 57af227#diff-b2ae385ada02a75ad946141c7af41540970760d41d02d54209c00eabdc9bc8e3L175

I suggest make "OR" condition. If we have options.timeout, we use it, otherwise we use client.getTimeout()

I haven't forgotten about:

  • Tests
  • Changelog
  • Documentation
  • Commit messages comply with the guideline
  • Cleanup the code for review. See checklist

Related issues:

@ArtDu ArtDu requested a review from akudiyar February 27, 2023 19:47
@ArtDu ArtDu marked this pull request as ready for review February 27, 2023 19:47
@@ -89,6 +89,10 @@ public void withTimeout() throws ExecutionException, InterruptedException {
List<?> crudDeleteOpts = client.eval("return crud_delete_opts").get();
assertEquals(requestConfigTimeout, ((HashMap) crudDeleteOpts.get(0)).get("timeout"));

profileSpace.delete(conditions, ProxyDeleteOptions.create()).get();
crudDeleteOpts = client.eval("return crud_delete_opts").get();
assertEquals(requestConfigTimeout, ((HashMap) crudDeleteOpts.get(0)).get("timeout"));
Copy link
Collaborator

Choose a reason for hiding this comment

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

Seems that setting the request timeout is missing here

Copy link
Collaborator

Choose a reason for hiding this comment

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

That also applies to all the other tests

CRUDBucketIdOptions requestOptions = new CRUDDeleteOptions.Builder()
.withTimeout(options.getTimeout())
.withTimeout(optionsTimeout.isPresent() ? optionsTimeout : requestTimeout)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure that we need two ways of setting the timeout. For what the other timeout (in options) then stands for? In the previous variant, the request timeout was passed to the response handler. I believe that we need to make them distinct timeouts and pass both of them in the options.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Passing in the options is optional, but passing to the handler is mandatory I think

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But the main think about the changes that we have passing config.requestTimeout

@Override
public CompletableFuture<R> select(Conditions conditions) throws TarantoolClientException {
return select(conditions, rowsMetadataTupleResultMapper(), ProxySelectOptions.create()
.withTimeout(config.getRequestTimeout())
);
}

For example if we used fields options we wouldn't have this feature and it might frustrate. This is the thing that @vlalykin complained:

добрый день.
по поводу возможности задания списка полей в options: #236

если я задаю новый параметр для уточнения списка полей, то не передается дефолтный таймаут (который раньше задавался один раз на уровне клиента). теперь его надо каждый раз руками задавать, или я что то неправильно делаю ?

client.getSpace(SPACE).select(condition, ProxySelectOptions.create().withFields(fields))

Copy link
Collaborator

Choose a reason for hiding this comment

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

The timeout that is passed currently to the options is different. We need to not pass the requestTimeout instead of that timeout, but rather pass this requestTimeout to the request handler as it was done previously (that's what the users want).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We always pass requestTimeout in crud option. See 0.8.0 version(it's before my options changes). Do you want to change this behavior?

Copy link
Collaborator

@akudiyar akudiyar Mar 3, 2023

Choose a reason for hiding this comment

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

Ah, it was broken since even then. Yes, I think that we need to pass the requestTimeout to Netty, and only the timeout in the options to tarantool/crud.

@ArtDu ArtDu requested a review from akudiyar February 28, 2023 13:42
Copy link
Collaborator

@akudiyar akudiyar left a comment

Choose a reason for hiding this comment

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

We need to return back the previous behavior, it is currently broken. The actual changes are doing something other.

@ArtDu ArtDu requested a review from akudiyar March 2, 2023 14:23
Copy link
Collaborator

@akudiyar akudiyar left a comment

Choose a reason for hiding this comment

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

We need to pass requestTimeout to the handlers and timeout in options to crud

Elishtar
Elishtar previously approved these changes Mar 6, 2023
@@ -275,7 +265,6 @@ private CompletableFuture<R> select(
.withSpaceName(spaceName)
.withFunctionName(operationsMapping.getSelectFunctionName())
.withConditions(conditions)
.withOptions(options)
Copy link
Contributor Author

@ArtDu ArtDu Mar 16, 2023

Choose a reason for hiding this comment

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

duplicate

@ArtDu ArtDu force-pushed the crud/timeout branch 2 times, most recently from 67c0825 to 4d106ef Compare March 16, 2023 20:30
@ArtDu ArtDu marked this pull request as draft March 16, 2023 20:34
@ArtDu ArtDu marked this pull request as ready for review March 16, 2023 20:51
@ArtDu ArtDu requested a review from akudiyar March 16, 2023 20:51
Copy link
Collaborator

@akudiyar akudiyar left a comment

Choose a reason for hiding this comment

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

LGTM, as it at least removes the ambiguity.

I've created a new issue #367 for implementing the requestTimeout option correctly.

@akudiyar akudiyar added this pull request to the merge queue Mar 16, 2023
Merged via the queue into master with commit b961c62 Mar 16, 2023
@akudiyar akudiyar deleted the crud/timeout branch March 16, 2023 22:01
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