Skip to content

Comments

Add BufWriter for Adapative Put / Multipart Upload#5431

Merged
tustvold merged 2 commits intoapache:masterfrom
tustvold:add-buffered-writer
Feb 27, 2024
Merged

Add BufWriter for Adapative Put / Multipart Upload#5431
tustvold merged 2 commits intoapache:masterfrom
tustvold:add-buffered-writer

Conversation

@tustvold
Copy link
Contributor

@tustvold tustvold commented Feb 26, 2024

Which issue does this PR close?

Closes #5205

Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

@tustvold
Copy link
Contributor Author

FYI @roeap @Samrose-Ahmed @Xuanwo

Self {
capacity,
store,
state: BufWriterState::Buffer(path, Vec::with_capacity(1024)),
Copy link
Member

Choose a reason for hiding this comment

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

It's by design to keep a 1024B buffer?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was a habit, as typically you want to avoid small bump allocations when pushing individual records. In this case poll_write is called with a slice of values, so this is not necessary. Will change


impl BufWriter {
/// Create a new [`BufWriter`] from the provided [`ObjectStore`] and [`Path`]
pub fn new(store: Arc<dyn ObjectStore>, path: Path) -> Self {
Copy link
Member

Choose a reason for hiding this comment

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

An off-topic question: I remember we planned to support content_type and custom metadata. How can we accommodate this use case in our current API design?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good spot, filed #5435

self.multipart_id = Some(id);
}
BufWriterState::Buffer(p, b) => {
let buf = std::mem::take(b);
Copy link
Member

Choose a reason for hiding this comment

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

In severe cases, poll_shutdown might return an error. Should we ensure that retrying poll_shutdown functions is safe?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What do you mean by safe? What is the issue if poll_shutdown returns an error?

Copy link
Member

Choose a reason for hiding this comment

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

Apologies for the confusion caused by my choice of the word "safe". I'm talking about this case:

  • write some data in buffer.
  • calling poll_shutdown, return error like 500 Internal Server.
  • calling poll_shutdown again for retrying.

But the buf has been take in the first call, so the final content could be wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

@wjones127 wjones127 left a comment

Choose a reason for hiding this comment

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

Looks good!

@tustvold tustvold merged commit ef5c45c into apache:master Feb 27, 2024
alamb pushed a commit to alamb/arrow-rs that referenced this pull request Mar 20, 2025
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