-
Notifications
You must be signed in to change notification settings - Fork 11
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
Conversation
@@ -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")); |
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.
Seems that setting the request timeout is missing 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.
That also applies to all the other tests
CRUDBucketIdOptions requestOptions = new CRUDDeleteOptions.Builder() | ||
.withTimeout(options.getTimeout()) | ||
.withTimeout(optionsTimeout.isPresent() ? optionsTimeout : requestTimeout) |
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'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.
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.
Passing in the options is optional, but passing to the handler is mandatory I think
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.
But the main think about the changes that we have passing config.requestTimeout
cartridge-java/src/main/java/io/tarantool/driver/core/space/ProxyTarantoolSpace.java
Lines 251 to 256 in 97f2a19
@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))
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.
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).
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.
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?
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.
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.
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.
We need to return back the previous behavior, it is currently broken. The actual changes are doing something other.
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.
We need to pass requestTimeout
to the handlers and timeout
in options to crud
@@ -275,7 +265,6 @@ private CompletableFuture<R> select( | |||
.withSpaceName(spaceName) | |||
.withFunctionName(operationsMapping.getSelectFunctionName()) | |||
.withConditions(conditions) | |||
.withOptions(options) |
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.
duplicate
67c0825
to
4d106ef
Compare
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.
LGTM, as it at least removes the ambiguity.
I've created a new issue #367 for implementing the requestTimeout
option correctly.
@ 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:
Related issues: