Skip to content
This repository has been archived by the owner on Mar 19, 2024. It is now read-only.

Upgrade sdk to rc10 #261

Merged
merged 6 commits into from
Aug 14, 2023
Merged

Upgrade sdk to rc10 #261

merged 6 commits into from
Aug 14, 2023

Conversation

smallhive
Copy link
Contributor

closes #260

@codecov
Copy link

codecov bot commented Aug 8, 2023

Codecov Report

Merging #261 (465257d) into master (e6e7941) will decrease coverage by 0.33%.
Report is 3 commits behind head on master.
The diff coverage is 24.29%.

@@            Coverage Diff             @@
##           master     #261      +/-   ##
==========================================
- Coverage   34.62%   34.29%   -0.33%     
==========================================
  Files          10       10              
  Lines        1369     1382      +13     
==========================================
  Hits          474      474              
- Misses        852      866      +14     
+ Partials       43       42       -1     
Files Changed Coverage Δ
downloader/download.go 8.15% <0.00%> (-0.16%) ⬇️
downloader/head.go 0.00% <0.00%> (ø)
settings.go 52.24% <ø> (-1.31%) ⬇️
uploader/upload.go 0.00% <0.00%> (ø)
app.go 60.74% <74.28%> (+2.76%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@smallhive smallhive marked this pull request as ready for review August 8, 2023 10:57
resolver/resolver.go Show resolved Hide resolved
app.go Show resolved Hide resolved
downloader/download.go Outdated Show resolved Hide resolved
downloader/head.go Show resolved Hide resolved
uploader/upload.go Outdated Show resolved Hide resolved
@smallhive smallhive force-pushed the 260-upgrade-sdk-to-rc10 branch 3 times, most recently from 15f0295 to 7a79448 Compare August 10, 2023 06:37
cthulhu-rider
cthulhu-rider previously approved these changes Aug 10, 2023
Copy link
Contributor

@cthulhu-rider cthulhu-rider left a comment

Choose a reason for hiding this comment

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

overall LGTM, some cosmetics may be applied

utils/util.go Outdated
func GetContainerID(ctx context.Context, containerID string, resolver *resolver.ContainerResolver) (*cid.ID, error) {
cnrID := new(cid.ID)
func GetContainerID(ctx context.Context, containerID string, resolver resolver.Resolver) (*cid.ID, error) {
cnrID := cid.ID{}
Copy link
Contributor

Choose a reason for hiding this comment

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

seems like useless change

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 change allows not to change other lines in the function

Copy link
Contributor

Choose a reason for hiding this comment

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

ok, missed that Resolve changed signature. I'd prefer

Suggested change
cnrID := cid.ID{}
var cnrID cid.ID

but dont mind

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

app.go Outdated Show resolved Hide resolved
downloader/download.go Outdated Show resolved Hide resolved
downloader/download.go Outdated Show resolved Hide resolved
return
}

for {
Copy link
Contributor

Choose a reason for hiding this comment

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

can io.CopyBuffer be used here? i see that we pass different messages into response.Error, but taking into account we always respond with 500 don't think it's worth code complication

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, but as how benchmark showed in Slicer, this isn't so effective and consumes more memory

Copy link
Contributor

Choose a reason for hiding this comment

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

then maybe add a comment about this before for so that this question does not arise in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good, but maybe I should make some local benchmark tests for object upload, separate from the slicer. Maybe it was a special case in than code.
Give me some time, I will post the result of my research here

Copy link
Member

Choose a reason for hiding this comment

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

I'd expect it to be around the same with io.Copy, but pay attention to buffer size (#148).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why? The object may be big. We need to read it part by part. Writing yes, right now a little bit shorter, but anyway

Copy link
Member

Choose a reason for hiding this comment

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

Why not just io.Copy()? This would do the trick without loops/maxsizes. It can also be optimized if we're to provide ReaderFrom (in the SDK) and/or WriterTo (in the multipart handler).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I consider we want to use bigger buffers. io.Copy uses 32kb buffers (if corresponding reader is not a LimitedReader, in our case in isn't), which too small, according to task #148.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But I agree, io.CopyBuffer will help to remove the for

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated to io.CopyBuffer

@smallhive
Copy link
Contributor Author

Updated objectPut with io package, make maxObjectSize configurable for Uploader

app.go Outdated
"github.com/nspcc-dev/neofs-sdk-go/user"
"github.com/spf13/viper"
"github.com/valyala/fasthttp"
"go.uber.org/zap"
)

const (
defaultObjectSize = int64(2 << 21) // 2MB
Copy link
Contributor

Choose a reason for hiding this comment

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

that's not 2MB but 4. If u need 2MB, then 1 << 21 or 2 << 20 (like more). If 4, then twice

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, thought about 2^21, and as a result 2 << 21. Updated to 1 << 21

continue
}

if !errors.Is(err, io.EOF) {
Copy link
Contributor

Choose a reason for hiding this comment

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

CopyN doesn't return EOF

Suggested change
if !errors.Is(err, io.EOF) {
if err != nil {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Returns and without this check, it doesn't work

app.go Outdated Show resolved Hide resolved
return
}

for {
Copy link
Member

Choose a reason for hiding this comment

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

Why not just io.Copy()? This would do the trick without loops/maxsizes. It can also be optimized if we're to provide ReaderFrom (in the SDK) and/or WriterTo (in the multipart handler).

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

Successfully merging this pull request may close these issues.

Upgrade SDK to RC10
3 participants