You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have observed an issue using transferManager.uploadDirectory with and uploadFileRequestTransformer supplied. In our code, after we have updated beyond version 2.25.18 the directory upload would complete while only actually uploading a small percentage of the files in the directory.
The reason for the failure is that the transformer we were supplying relied on a thread local variable. This variable was not present after the initial buffer of 100 in flight requests was exhausted in AsyncBufferingSubscriber. After the 100 threads were exhausted the subsequent requests are built inside the sdk-async-response which did not have access to the thread local variable and threw an exception. This exception appears to be swallowed without report in code or logging. I have discovered using logging that the currently in flight requests are cancelled in the background with exceptions only logged at the debug level.
We have fixed the transformer so it no longer fails, but would like it such that the same scenario happens again, the SDK actually indicates that the directory upload has failed. As a result of the failure not being thrown our own software reported that the upload was successful, which is undesirable.
Regression Issue
Select this option if this issue appears to be a regression.
Expected Behavior
I expected the exception to be recorded on the completable future that is used as the response to the upload directory request as a failed transfer.
Current Behavior
The application instead swallows the original exception generated by the upload file transformer and the completable future returned by the directory upload request indicates no errors have occurred.
@plovell thank you for the detailed report. Just to confirm: the issue only started to happen after you upgraded to 2.29.10, it didn't happen with 2.25.18, is that right?
I believe that the issue was caused as a side effect of the change to use AsyncBufferingSubscriber to limit the number of concurrent threads for directory uploads.
This happened between 2.25.18 and 2.25.19. This is from my own experimentation however.
Previously we were using a much older version and noticed it when we moved to 2.27.x
Describe the bug
We have observed an issue using transferManager.uploadDirectory with and uploadFileRequestTransformer supplied. In our code, after we have updated beyond version 2.25.18 the directory upload would complete while only actually uploading a small percentage of the files in the directory.
The reason for the failure is that the transformer we were supplying relied on a thread local variable. This variable was not present after the initial buffer of 100 in flight requests was exhausted in AsyncBufferingSubscriber. After the 100 threads were exhausted the subsequent requests are built inside the sdk-async-response which did not have access to the thread local variable and threw an exception. This exception appears to be swallowed without report in code or logging. I have discovered using logging that the currently in flight requests are cancelled in the background with exceptions only logged at the debug level.
We have fixed the transformer so it no longer fails, but would like it such that the same scenario happens again, the SDK actually indicates that the directory upload has failed. As a result of the failure not being thrown our own software reported that the upload was successful, which is undesirable.
Regression Issue
Expected Behavior
I expected the exception to be recorded on the completable future that is used as the response to the upload directory request as a failed transfer.
Current Behavior
The application instead swallows the original exception generated by the upload file transformer and the completable future returned by the directory upload request indicates no errors have occurred.
Reproduction Steps
The following code reproduces the issue:
`
package com.smartcommunications.tools.aws;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3AsyncClient;
import software.amazon.awssdk.transfer.s3.S3TransferManager;
import software.amazon.awssdk.transfer.s3.model.*;
import software.amazon.awssdk.transfer.s3.progress.TransferListener;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.file.Path;
import java.util.Random;
import java.util.concurrent.atomic.AtomicLong;
public class S3TestTool {
}
`
This test will return the following:
Transfer completed with no recorded failures.
Test failed - only transferred X, of 10752000 bytes.
Where X < 10752000
Possible Solution
No response
Additional Information/Context
No response
AWS Java SDK version used
SDK 2.29.10 CRT 0.33.0
JDK version used
openjdk version "17.0.8" 2023-07-18 OpenJDK Runtime Environment Temurin-17.0.8+7 (build 17.0.8+7) OpenJDK 64-Bit Server VM Temurin-17.0.8+7 (build 17.0.8+7, mixed mode, sharing)
Operating System and version
Windows 11
The text was updated successfully, but these errors were encountered: