-
Notifications
You must be signed in to change notification settings - Fork 42
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 connect_timeout inside set_keyspace_blocking
#259
Conversation
@Lorak-mmk I need you review on this one, at least it's pass the integration test. And I think it's relatively harmless change |
It would be good to have a tests that executes the timeout path - but if it's too hard to write then I think we can skip it. |
we might be able to copy the dtest casing it, but it wasn't 100% of the time... |
it might be a bit tricky, and we are still trying to find the root cause of that issue, and simulated the situation which we don't know it's exact root case, it kind of futile. |
`set_keyspace_blocking` is called from places holding a lock, and in case that the connection is closed from the server side, it might hang forever. using the `connect_timeout` on it to make sure it won't hang forever. Ref: https://github.com/scylladb/scylladb/issues/15661
6c8bd51
to
b756779
Compare
This is actually a backwards-incompatible change, the behavior of the function is different and there might be users depending on current behavior. |
That's what one would expect, but some when it works with TLS behaves differently and no part identifies the connection is closed, when TLS is the lower version it doesn't hang there. We can have higher number, but having queries with no timeout at all seems like a recipe for trouble, especially when there's a lock involved |
Closed in favor of #362 |
set_keyspace_blocking
is called from places holding a lock, and in case that the connection is closed from the server side, it might hang forever.using the
connect_timeout
on it to make sure itwon't hang forever.
Ref: #261