Closed neverendingqs closed 1 day ago
I've seen this behaviour too. If you have many parallel transfers inititated (more than your CPU count), and need concurrency, you may need to raise java.util.concurrent.ForkJoinPool.common.parallelism.
Hi @neverendingqs , could you provide the following information:
Are you using CompletableFuture#runAsync
or CompletableFuture#supplyAsync
in your application? If no executor is provided, the task will be performed by ForkJoinPool
I see you have a support case open, feel free to share with them if it works better for you. I don't think we use ForkJoinPool in the SDK and I searched our code base and couldn't find places where we use CompletableFuture#xxxAsync
methods in the S3 client without overriding the executor.
It looks like this issue has not been active for more than five days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.
Hi @neverendingqs I've reviewed the code. It seems you are using parallel streams to invoke concurrent requests. By default, parallel streams use ForkJoinPool. If the behavior is not desired, I'd suggest using a custom executor to submit those requests instead.
StreamSupport.stream(var.spliterator(), true)
It looks like this issue has not been active for more than five days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.
Describe the bug
I think
CompletableFuture
s seems to always be on or reverts to the default sharedForkJoinPool
even if anExecutor
is provided viaFUTURE_COMPLETION_EXECUTOR
when makingS3TransferManager
calls.Expected Behavior
If provided,
CompletableFuture
s run on theExecutor
provided viaFUTURE_COMPLETION_EXECUTOR
when makingS3TransferManager
calls.Current Behavior
CompletableFuture
s uses or reverts back to the default sharedForkJoinPool
even if anExecutor
is provided via.futureCompletionExecutor()
when makingS3TransferManager
calls.Reproduction Steps
Disclaimer: this is the first time I've worked with
Executor
s andCompletableFuture
s.On
2.20.160
of the SDK (SDK version because it currently runs on EMR6.15.0
), when attempting something likein production code that attempts to do many
S3TransferManager
calls, I geteven though the executor is a
ThreadPoolExecutor
andRejectedExecutionHandler
is set toThreadPoolExecutor.CallerRunsPolicy
.Local testing on some scratch code shows that the
CompletableFuture<CompletedFileDownload>
object hasstack.executor
asnull
, and callingCompletableFutureUtils.forwardResultTo(sdkFuture, customFuture, futureCompletionExecutor);
changesstack.executor
to theExecutor
I provided. This seems to suggest the SDK was using the defaultForkJoinPool
Executor
before I changed it viaCompletableFutureUtils.forwardResultTo()
.Scratch code (SDK:
2.26.9
,software.amazon.awssdk.crt.aws-crt
:0.29.20
):Possible Solution
No response
Additional Information/Context
JDK and SDK versions are provided in-line under
Reproduction Steps
.Versions for the fields below will be based on production, which is using EMR 6.15.0.
AWS Java SDK version used
2.20.160
JDK version used
Amazon Corretto 8
Operating System and version
Amazon Linux 2.0.20240610.1