This looks indeed promising! I'd like to see the feature properly aligned in the drivers layer. OkHttp also provides a way to perform async requests [1] and we should also explore including it in the changeset for this feature.
[1] https://github.com/square/okhttp/wiki/Recipes On Mar 16, 2017 1:06 AM, "Andrew Gaul" <g...@apache.org> wrote: Spandan, thanks for creating this proof of concept! Generally this idea shows promise and should give value to the wider jclouds community. We might want to support get blob as well as put blob for symmetry, although this raises more questions. In terms of structuring, you must isolate all the Apache HTTP client changes in drivers/apachehc. Only users who configure the apachehc driver can use async otherwise jclouds should throw an exception. This means fields like BaseHttpCommandExecutorService.httpRequestExecutor migrate to ApacheHCHttpCommandExecutorService. I am a bit confused how you track completion of these Futures since you return an empty CompletableFuture[1]. I added some comments in your tree mostly about structuring and some specific questions. The commit has style, exception handling, and logging issues we can deal with when you submit the actual pull request. [1] https://github.com/SpandanThakur/jclouds/commit/ 00c378bd07aea07f3cebf4446eae373cdcde1e37#diff-a7d2c9d5b9ddcf7805dd36326f85dc 4bR102 On Wed, Mar 08, 2017 at 11:58:59AM -0000, Spandan Thakur wrote: > Hi Andrew, > > I done a quick Proof of Concept in to add a Azure BlobStore putBlob Async method: > > https://github.com/SpandanThakur/jclouds/tree/AsyncPOC > > Important Classes to look at are: > AzureBlobClient.java > InvokeHttpMethod.java > HttpCommandExecutorService.java (Have a look at this class to see how call back is assigned) > BaseHttpCommandExecutorService.java > > In S3 proxy we would suspend the jetty thread, complete the future and then continue the thread. > > Though my example moves to java 8, I think we should be able to use guava and stay on current java version. Also we have not yet decided how many methods we want to make async. > > As far as benefits goes, we saw that the S3 proxy throughput is throttled by the number of threads in the jetty server. When load is greater than the jetty threads performance degrades. Where as when we move a async implementation we are able to scale to any load (till CPU becomes a bottle neck) using even one jetty thread. Even when the load is less than the number of jetty threads the async gives slightly better throughput and response times. > > I also wanted to know if you guys have any standard performance tests that you guys run? I could try running them on the POC. > > Please let me know if you guys feel that my approach is correct and if this will benefit jClouds overall. > > Regards, > Spandan > -- Andrew Gaul http://gaul.org/
