Skip to content
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

Get accurate start time and bytes started for each file uploaded to Remote Translog Store #9729

Open
BhumikaSaini-Amazon opened this issue Sep 4, 2023 · 0 comments
Labels
enhancement Enhancement or improvement to existing feature or request Storage:Remote Storage Issues and PRs relating to data and metadata storage

Comments

@BhumikaSaini-Amazon
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Currently, there is no way to capture the exact start time for a given file being uploaded to the Remote Translog Store. This information is essential to emit an accurate time duration spent on uploads.

Additionally, the same solution can be leveraged to emit the more accurate, point-in-time value of upload bytes started for Remote Translog Store uploads.

Describe the solution you'd like
Currently, we depend on the ActionListener interface and LatchedActionListener to run logic on a successful or failed response for the remote upload:

https://github.com/opensearch-project/OpenSearch/blob/d375e4cfea1a8e4c58dd1409365a67cf49366780/libs/core/src/main/java/org/opensearch/core/action/ActionListener.java

https://github.com/opensearch-project/OpenSearch/blob/d375e4cfea1a8e4c58dd1409365a67cf49366780/server/src/main/java/org/opensearch/action/LatchedActionListener.java

However, there is no way to pass a beforeUpload callback here. There is ActionListener#runBefore(), but that is triggered before passing on the received response. What we need is a way to trigger some logic before starting the actual upload.

Describe alternatives you've considered
For the meantime, we are planning to consider the start time of sync to remote as the start time for calculating the time duration spent on uploads. Similarly, we add all the bytes of all files being attempted in the sync as the uploadBytesStarted value to add. Consequently, these values would likely be somewhat higher than the actual point-in-time values.

Additional context

Current callback logic on upload success:

@Override
public void onSuccess(TransferFileSnapshot fileSnapshot) {
add(fileSnapshot.getName(), TransferState.SUCCESS);
}

Current callback logic on upload failure:

@Override
public void onFailure(TransferFileSnapshot fileSnapshot, Exception e) {
add(fileSnapshot.getName(), TransferState.FAILED);
}

assert ex instanceof FileTransferException;
logger.error(
() -> new ParameterizedMessage(
"Exception during transfer for file {}",
((FileTransferException) ex).getFileSnapshot().getName()
),
ex
);
FileTransferException e = (FileTransferException) ex;
fileTransferTracker.onFailure(e.getFileSnapshot(), ex);
exceptionList.add(ex);
}),
latch

Initial changes for capturing the upload start time and upload bytes started are being added as part of #9263

@BhumikaSaini-Amazon BhumikaSaini-Amazon added enhancement Enhancement or improvement to existing feature or request untriaged labels Sep 4, 2023
@tlfeng tlfeng added Indexing:Replication Issues and PRs related to core replication framework eg segrep Storage Issues and PRs relating to data and metadata storage labels Sep 5, 2023
@kotwanikunal kotwanikunal added the Indexing Indexing, Bulk Indexing and anything related to indexing label Sep 19, 2023
@anasalkouz anasalkouz added Storage:Remote and removed Indexing:Replication Issues and PRs related to core replication framework eg segrep Indexing Indexing, Bulk Indexing and anything related to indexing labels Sep 21, 2023
@gbbafna gbbafna moved this from 🆕 New to Ready To Be Picked in Storage Project Board Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or improvement to existing feature or request Storage:Remote Storage Issues and PRs relating to data and metadata storage
Projects
Status: Ready To Be Picked
Development

No branches or pull requests

5 participants