Add injection of custom executor service to S3Base supplyAsync calls

[delta11]

We have a use case where we need to provide our own thread pool for the CompletableFuture.supplyAsync to run on, currently that's not possible and it's preventing us from keeping up with library upgrades.

[chenshi5012]

@delta11 refer #1569

can you give some advice about this issue.

[delta11]

@delta11 refer #1569

can you give some advice about this issue.

Seems like 2 unrelated issues, this one is about giving flexibility to control which executor service get's used not what it get's used for.

[balamurugana]

Any custom requirements should be done by inheriting S3Base and override whatever methods you want. I am not sure why we need to take this into minio-java.

[delta11]

Any custom requirements should be done by inheriting S3Base and override whatever methods you want. I am not sure why we need to take this into minio-java.

We are in an environment where we can't use the regular ForkJoinPool.commonPool() (which CompletableFuture.supplyAsync uses by default).

But in this situation allowing users to optionally supply their own ExecutorService would be preferable over having to override half a dozen rather methods of S3Base and the MinioAsyncClient to change CompletableFuture.supplyAsync(....) into CompletableFuture.supplyAsync(....,executorService).

Though we understand that this is an uncommon requirement, it would still be a great help to us if we can provide our own and I imagine there might be some other niche use cases that would benefit. Let me know what you think!

[lexakimov]

Any updates regarding this feature? It might be useful for propagation of micrometer observation context to okHttp3 client thread.

[delta11]

Maybe @balamurugana could have another look? I'd be happy to revise it if there's anything you'd like to see different.

[fer-marino]

+1 on this. In our use case we need to control the task executor as the ForkJoinExecutor is not suitable.

to add more details: our use cases is an integration test in a dockerized environment with very limited resources and the ForkJoinExecutor hangs.

[jgolda]

A huge +1 on this issue. I'm willing to help in case any help is required.

My scenario is that i need to perform some actions in InputStream's read methods (mainly updating download/upload progress). Since these methods are called in a different thread, i'm losing all the thread locals which are crucial for this. Currently i'm stuck with some prehistoric minio-java version.

In case this PR goes through, it should be possible to provide an ExecutorService running on the caller thread, fixing my problem, despite being slightly hacky.

[mmadoo]

I need to add following commit to be able to compile: mmadoo@8c0fd20

I create the PR delta11#1 to fix this branch

[balamurugana]

As alternative approach of PR #1665 is taken care in #1621, I am closing this.