Hi, The async implementation produced some unnecessary overhead and complexity that was actually out of the scope of jclouds. Applications that perform async tasks should control the executors, thread pools, etc, in order to properly setup them according to their concurrency needs.
The jclouds async interfaces used an internal jclouds executor that exposed just a bunch of configuration options. Instead of internally dealing with custom executors, their lifecycle, and exposing just some configuration, we think it is better to leave them out of the scope of jclouds and let any user use their own application ones. I. On 24 February 2017 at 06:33, Spandan Thakur <spandan.thakur1...@gmail.com> wrote: > Hi, > > We noticed that 3-4 years back jClouds had async implementations which was > then deprecated and removed: https://issues.apache.org/jira/browse/JCLOUDS-40 > > We were wondering why this decision to deprecate the Async implementation was > made? > > The reason I ask this question is that we are using a S3 proxy > (https://github.com/andrewgaul/s3proxy) which internally uses jClouds. The > problem is that the throughput is limited by the number of threads in the > server to handle the request. We were planning to do changes to go to async > for better performance and then we noticed your jira issue to remove async. > > Regards, > Spandan Thakur
