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

Decouple schema fetch queries from server-side timeouts #1052

Open
dkropachev opened this issue Aug 4, 2024 · 4 comments · May be fixed by #1171
Open

Decouple schema fetch queries from server-side timeouts #1052

dkropachev opened this issue Aug 4, 2024 · 4 comments · May be fixed by #1171
Assignees
Milestone

Comments

@dkropachev
Copy link
Collaborator

Details

If the user set server-side timeouts, or service level timeouts, this impacts schema fetches. The timeout can be too low to allow a schema fetch when the schema is very large.

Instead, qualify schema (and other metadata) fetches with USING TIMEOUT (with a high and configurable default) so schema fetches work regardless of timeout tuning.

Core issue: scylladb/scylladb#18471

Limitations

  1. USING TIMEOUT is not supported by cassandra and support by all major scylla versions, so it is safe to assume it is supported by seeing scylla-specific metadata.
  2. Minimal supported scale is ms, so statement suffix should look like this: USING TIMEOUT {timeout_in_ms} ms

Requirements

  1. Timeout should be configurable and default should be 2s
  2. 0 signals that feature is disabled
@wprzytula wprzytula changed the title Rust implementation of "Decouple schema fetch queries from server-side timeouts" Decouple schema fetch queries from server-side timeouts Aug 6, 2024
@wprzytula wprzytula added this to the 0.16.0 milestone Aug 20, 2024
@Lorak-mmk Lorak-mmk modified the milestones: 0.16.0, 1.x.0 Nov 29, 2024
@roydahan roydahan modified the milestones: 1.x.0, 1.1.0 Dec 18, 2024
@mykaul
Copy link
Contributor

mykaul commented Jan 7, 2025

We've implemented it in all other drivers, we see customers hit by this in the field - I don't understand why it's a 1.1.0 content and not sooner.

CC @roydahan

@Lorak-mmk
Copy link
Collaborator

We have a deadline for 1.0 and we won't be able to keep it if we add more stuff there.
In contrary to the changes that we will include in 1.0, this one can actually be implemented in 1.1.

@mykaul
Copy link
Contributor

mykaul commented Jan 7, 2025

We have a deadline for 1.0 and we won't be able to keep it if we add more stuff there. In contrary to the changes that we will include in 1.0, this one can actually be implemented in 1.1.

Create a release before 1.0 with that fix. A mythical '1.0' cannot have a priority over real customer issues.

@wprzytula wprzytula modified the milestones: 1.1.0, 0.16.0 Jan 8, 2025
@wprzytula wprzytula assigned wprzytula and unassigned Lorak-mmk Jan 8, 2025
@wprzytula wprzytula linked a pull request Jan 17, 2025 that will close this issue
8 tasks
@roydahan
Copy link
Collaborator

This is a new feature, not going to be merged into 0.15.
Nice to have for 1.0.0, only if it makes it in time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants