Send white spaces to client till completeMultipart() process completes#7198
Conversation
e5954f4 to
d5f55a9
Compare
Codecov Report
@@ Coverage Diff @@
## master #7198 +/- ##
==========================================
+ Coverage 49.04% 49.09% +0.04%
==========================================
Files 289 289
Lines 45207 45229 +22
==========================================
+ Hits 22174 22203 +29
+ Misses 21005 21001 -4
+ Partials 2028 2025 -3
Continue to review full report at Codecov.
|
d5f55a9 to
2e50a02
Compare
Mint Automation
7198-2e50a02/mint-gateway-nas.sh.log:7198-2e50a02/mint-dist-xl.sh.log: |
|
Thank you so much guys. The white spaces are sent regardless of the backend right? |
|
@challarao yes |
|
Thanks Krishna. This is needed for Abort Multipart as well? |
|
abort is always quick @challarao |
|
Hi 👋 We're running minio GCS gateway on Google Kubernetes Engine for our end-to-end tests and since last week (we're running minio's docker Googling around we've stumbled upon this issue which has been fixed in this PR in june 2016 with code that added the XML header first, then whitespaces and finally the content. But then about two month later this has been changed to not send whitespaces anymore, which, I assume, still works as long as timeouts are long enough. And finally this PR reintroduces the whitespaces, but before the XML header, which seems to break the Java AWS SDK parser. Let me know if my analysis is correct or not, I'll try a new deployment with the tag |
|
Whitespaces should be ignored, this is a bug in AWS SDK implementation. We will validate it nonetheless. |
|
🤐 |
|
FWIW our tests run fine with |
|
@arnaudbos We have the same problem as described by you. Have you reported the issue to the Java AWS S3 SDK team yet? Our workaround for now is to catch the exception and make sure the completeMultipart() was succeeded by checking if the object exists. |
|
The issue regarding Java SDK should be fixed #7253 |
|
Oh wow, that was fast! Thank you for all the hard work on Minio, it works well for our use case and saved us a lot of time to test our system's multipart upload on GCP without switching from AWS SDK. |
Description
FS backend can take a long time in completeMultiPartUpload() if parts came in an order not favorable to background append OR if bandwidth between server and client is so high that background append is not fast enough causing completeMultiPartUpload() to be not quick. In such a situation we can send white spaces to the client just like aws-s3 server so that the client connection does not time out.
http://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadComplete.html
#3223
Motivation and Context
Regression
No
How Has This Been Tested?
tested by putting sleep/print statements to see if whitespace was being sent.
Types of changes
Checklist:
mintPR # here: )