add connect_timeout inside set_keyspace_blocking#259
add connect_timeout inside set_keyspace_blocking#259fruch wants to merge 1 commit intoscylladb:masterfrom
set_keyspace_blocking#259Conversation
|
@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_blockingis 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_timeouton it to make sure itwon't hang forever.
Ref: #261