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
IQSS/6993-use-single-AWS-client-per-store #6994
IQSS/6993-use-single-AWS-client-per-store #6994
Conversation
also refactor S3StorageIO to re-use single client per store, use more static methods
Nominally useful if code ever changes the storageIdentifier of the dvObject after the S3AccessIO instance is created, but real code shouldn't do that :-)
and the dataset pid being set multiple times.
for directUpload case
used in DatasetPage and editFilesFragment.xhtml
Conflicts: src/main/webapp/resources/js/fileupload.js
Conflicts: src/main/java/edu/harvard/iq/dataverse/DatasetPage.java src/main/webapp/resources/js/fileupload.js
keeping the cancel delay at 1 second - any queued uploads need to finish.
Conflicts: src/main/java/edu/harvard/iq/dataverse/api/Datasets.java
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
@qqmyers could you please sync up the branch with develop? - There are are no conflicts, but updating the version in pom.xml would help with QA deployments.
Everything appears to work. I was also curious to measure how much exactly we are saving per access call... Got strange results, then realized my experiment was faulty... Then decided not to hold the PR on account of it. So maybe I can instead help with that during QA (since it really is a QA task).
What this PR does / why we need it: Refactors the S3AccessIO class to avoid creating a new AWS client for each instance, and instead keeping track of one AWS client per store.
Which issue(s) this PR closes:
Closes #6993
Special notes for your reviewer:
Suggestions on how to test this: This should do nothing :-) - behavior should be the same (except lower memory use perhaps). Since it's S3-related, testing should focus on getting/putting files to S3. Nominally, since the change is related to keeping track of S3 stores correctly, testing should probably use a couple stores and verify that read/writes are still happening to the correct store/bucket.
Does this PR introduce a user interface change? If mockups are available, please link/include them here: No
Is there a release notes update needed for this change?: No
Additional documentation: