-
Notifications
You must be signed in to change notification settings - Fork 120
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
Tensorstore key value store driver not Retrying on 429 Responses with S3 API #194
Comments
The retry decision happens here (or one of the other methods in the file):
You could turn on logging. |
Unfortunately #149 doesn't integrate with any kvstore at present. |
Yea, I've tried turning on Logging as well with no output specifying any retries. I see that the 429 response is received and nothing beyond that other than a failure. |
Ah, this is unfortunate to hear, would it non-trivial to integrate? |
It'd take some work, I guess the amount of code required would be smaller than the current s3 kvstore as it could defer to the C++ S3 SDK. However, the C++ SDK is a fairly heavy dependency: the S3 C CRT looks much lighter. That's next, when I find the time. |
With Also, you could attempt to run localstack_test against OCI object storage.
|
Hey, I've tried turning on logging and I don't seem to see any logs regarding s3 being printed. |
Ok, so there was an issue that tensorstore logging when used from python didn't initialize the absl logging level in a way which provides output. This was fixed by 041a999 and I will make another release soon. I would expect that logging in gunit tests would work, though you may need gunit specific flags for that such as --gmock_verbose=info |
I'm using Tensorstore's key value store driver with OCI object storage using their S3 compatibility layer and am seeing that when the OCI Object Storage service sends 429s Tensorstore fails immediately without any retries. This was tested with debug logging enabled which also didn't show any retries happening either with the default value of 32 or with
s3_request_retries
set to a custom number.I also tried testing this @sjperkins 's PR here to see if that may enable retries to work here however I'm hitting bazel build issues on a M1 Mac of:
I was wondering if there was anything I could do to debug the lack of retries further or any modifications I could make to force retries.
The text was updated successfully, but these errors were encountered: