-
Notifications
You must be signed in to change notification settings - Fork 188
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
Uploader refactoring and additional attempts for immediate uploaders #1724
Conversation
private final List<S3UploadMetadata> immediateUploadMetadata; | ||
private final ReentrantLock lock; | ||
private final ConcurrentMap<SingularityUploader, Future<Integer>> immediateUploaders; | ||
private final Map<S3UploadMetadata, SingularityUploader> metadataToimmediateUploader; |
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.
nit metadataToimmediateUploader
-> metadataToImmediateUploader
(capitalize immediate)
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.
fixed
LOG.debug("Retrying immediate uploader {}", uploaderMetadata); | ||
performImmediateUpload(uploader); | ||
} else { | ||
LOG.debug("Uploader for metadata {} not found to retry, recreating", uploaderMetadata); |
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.
not sure I understand this debug line. What is being re-created?
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.
Ah, copy-pasta error. the ,recreating should be removed, if we don't find the uploader in the map it means it somehow got added to both toRemove and toRetry, which theoretically should never happen, but better than throwing a NPE, updated the message
SingularityUploader uploader = metadataToimmediateUploader.remove(uploaderMetadata); | ||
if (uploader != null) { | ||
LOG.debug("Retrying immediate uploader {}", uploaderMetadata); | ||
performImmediateUpload(uploader); |
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.
For this retry loop, the uploader is removed from metadataToImmeditateUploader
and when it's called to upload immediately, it'll be added to the immediteUploadersFutures
map. During the next run of checkUploads
, won't the uploader be missing from metadataToImmediateUploader
and cause the check to skip adding the uploadedFiles to the total count? Instead it'll be moved to the toRemove
list and hit the 30 second check
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.
good catch. It ends up working out that it still retries, but that should be a .get so we can do the full retry -> toRemove loop . Fixed
lgtm 🚢 |
@darcatron I'm folding #1714 into this as well to avoid too many merge conflicts. Will close the other when they are both in hs_qa
There were a few cases where an immediate uploader could miss files. Particularly, if an uploader was immediate, but then something attempted to recreate it (wrote the file again), before the original one expired and was removed. This updates the uploader driver to: