Closed JustinKyleJames closed 3 weeks ago
The entry in shared memory is cleaned up when CompleteMultipartUpload or AbortMultipartUpload returns. However, if neither is called it won't be cleaned up until the server restarts.
Should we consider cleaning up the entry in shared memory if a certain amount of time passes? Aka a timeout on idle shared memory entries? If so... what is a safe amount? An hour of no activity? A day? A week?
The entry in shared memory is cleaned up when CompleteMultipartUpload or AbortMultipartUpload returns. However, if neither is called it won't be cleaned up until the server restarts.
Should we consider cleaning up the entry in shared memory if a certain amount of time passes? Aka a timeout on idle shared memory entries? If so... what is a safe amount? An hour of no activity? A day? A week?
I think the ListMultipartUpload could return those and CancelMultipartUpload already cleans this up so I think that would be sufficient.
very impressive. glad this is behaving.
we have existing tests? new tests?
For the most part the existing tests should suffice. I did have a problem with missing the last close which would cause a second put to that object to fail if done too quickly. I just updated the tests to follow up the first large file put with a second one for each of the clients.
Is this ready to be squashed?
Yes, proceed with squashing if it's passing the tests.
Yes, proceed with squashing if it's passing the tests.
I have squashed.
Note that I also corrected my .vimrc file which was no longer highlighting spaces at the end of lines. I noticed some of these in my docker-compose.yml so removed those. Other than that this is identical to what you reviewed.
Please capture the design/ideas behind the multipart enhancements in the commit body of 45508f5.
Please capture the design/ideas behind the multipart enhancements in the commit body of 45508f5.
I added the design in the commit message.
D'oh. I misread the request for the design description. Looks good
This is the for multipart enhancement described in https://github.com/irods/irods_client_s3_api/issues/114.
I have also implemented AbortMultipartUpload.
Notes:
A couple of other concerns/questions:
The entry in shared memory is cleaned up when CompleteMultipartUpload or AbortMultipartUpload returns. However, if neither is called it won't be cleaned up until the server restarts. A new call to InitiateMultipartUpload would generate a new upload_id so that upload should behave correctly.