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

Administrative retry settings are not modifiable #2454

Closed
Sourc opened this issue May 22, 2023 · 2 comments
Closed

Administrative retry settings are not modifiable #2454

Sourc opened this issue May 22, 2023 · 2 comments
Assignees
Labels
api: spanner Issues related to the googleapis/java-spanner API.

Comments

@Sourc
Copy link

Sourc commented May 22, 2023

Hi, I noticed that the administrative retry settings used for the com.google.cloud.Spanner.DatabaseAdminClient#updateDatabaseDdl method are not exposed. The retry settings used seem to only be modifiable from here.

I presume this is an oversight, unless there's another hidden way to change them that I've missed.

@product-auto-label product-auto-label bot added the api: spanner Issues related to the googleapis/java-spanner API. label May 22, 2023
@olavloite
Copy link
Collaborator

This is intentional. Those settings are only used specifically for the case that the limit for the number of administrative requests has been reached:

This is an internal retry loop and hence these settings are also intentionally internal. If you for example were to reduce the retry backoff of these settings, you would probably end up making your system less responsive, as the more frequent retries would just cause the additional requests to cause the limit to be exceeded all the time.

@Sourc
Copy link
Author

Sourc commented May 22, 2023

I presume a lot of settings can cause things to behave sub optimally in different situations, I don't see why these settings should be hidden - seeing as they affect functionality just as much as other retry settings, and making them modifiable wouldn't cause any issues, as long as the default settings are unchanged. We have a need to disable these and manage the quota exceeded retries ourselves, which we unfortunately can't do without ugly workarounds now.

In our case, we have a bunch of updateDdl calls coming from a lot of different servers, but often using the same operation ID. If the default updateDdl implemention retried using for example getOperation instead of just trying to issue the initial request every time, we would be fine as well (since that quota is larger) - but since the current implementation doesn't we need to manually handle it for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: spanner Issues related to the googleapis/java-spanner API.
Projects
None yet
Development

No branches or pull requests

3 participants