Skip to content

Refactor to storages to support async reads #2012

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

Merged
merged 1 commit into from
Jan 8, 2025
Merged

Conversation

willdealtry
Copy link
Collaborator

Wrap the storage methods in an async interface, add methods that return KeySegmentPairs directly, get rid of composite from the storage interface

@willdealtry willdealtry changed the title WIP Refactor to async Refactor to storages to support async reads Dec 10, 2024
@willdealtry willdealtry force-pushed the refactor_to_async branch 2 times, most recently from 0c6203a to 9a33876 Compare December 10, 2024 18:11
@willdealtry willdealtry marked this pull request as ready for review December 11, 2024 10:02
@willdealtry willdealtry force-pushed the refactor_to_async branch 2 times, most recently from 8061d37 to b761182 Compare December 18, 2024 16:00
@willdealtry willdealtry force-pushed the refactor_to_async branch 2 times, most recently from c8989e8 to 0486da9 Compare January 6, 2025 17:01
blob_name,
static_cast<int>(e.StatusCode),
e.ReasonPhrase));
} catch(const std::exception&) {
Copy link
Collaborator

@poodlewars poodlewars Jan 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we now catching std::exception here? Is this intentional? If so, why only for read?

if(!failed_deletes.empty())
throw KeyNotFoundException(Composite<VariantKey>(std::move(failed_deletes)));
if (!failed_deletes.empty())
throw KeyNotFoundException(failed_deletes);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

request.WithBucket(bucket_name.c_str()).WithKey(s3_object_name.c_str());
request.SetResponseStreamFactory(S3StreamFactory());
ARCTICDB_RUNTIME_DEBUG(log::version(), "Scheduling async read of {}", s3_object_name);
s3_client.GetObjectAsync(request, GetObjectAsyncHandler{std::move(promise)});
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the callback is executed in a thread pool managed by AWS SDK? Do we need to set its size somewhere or is it sensibly sized by default?

@willdealtry willdealtry merged commit 32341ae into master Jan 8, 2025
124 of 125 checks passed
@willdealtry willdealtry deleted the refactor_to_async branch January 8, 2025 16:24

thread_local std::ostringstream oss;
for (int i = 0; i < num_frames; ++i) {
auto filtered = removePrefix(symbols[i], "/opt/arcticdb/arcticdb_link/python/arcticdb_ext.cpython-38-x86_64-linux-gnu.so");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you drop a more general prefix? This stripping will only work for certain dev setups

@@ -1905,7 +1943,7 @@ void set_row_id_if_index_only(
if (read_query.columns &&
read_query.columns->empty() &&
pipeline_context.descriptor().index().type() == IndexDescriptor::Type::ROWCOUNT) {
frame.set_row_id(pipeline_context.rows_ - 1);
frame.set_row_id(static_cast<ssize_t>(pipeline_context.rows_ - 1));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not your problem, but confused why the row_id is a ssize_t but pipeline_context.rows_ is size_t

Copy link
Collaborator

@poodlewars poodlewars left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only important thing I spotted was this one #2012 (comment) otherwise looks good

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

Successfully merging this pull request may close these issues.

3 participants