Plus, if you are using google storage, it will automatically use SPDY :P
On Fri, Oct 3, 2014 at 12:05 PM, Adrian Cole <[email protected]> wrote: > Glad to hear it worked. > > Disclaimer: I am a committer on okhttp. > > OkHttp acknowledges that the JRE HttpUrlConnection class has not been > awesome, particularly if someone wants a similar experience across jre > versions and android. It has a lot of tests around network and TLS > concerns. I'd recommend using it, eventhough we could probably > configure it better in our driver. > > http://square.github.io/okhttp/ > > -A > > On Fri, Oct 3, 2014 at 11:02 AM, Yury Kats <[email protected]> wrote: >> Awesome, this worked! Thank you! >> >> And please ignore my previous comment about non-default drivers not being >> used. >> It was a user error -- I put into wrong code path, so it wasn't exercised. >> >> But providing my own SSL context is even better. >> >> So there is definitely something's wrong with the default http driver as far >> as ssl/connection handling. Something's cached forever. >> >> Aside from this SSL issue, are there any other reasons for me to look at >> okhttp or apachehc drivers? >> >> Thanks again! >> >> On 10/3/2014 1:22 PM, Adrian Cole wrote: >>> That sounds very strange indeed. I don't have an answer for how to >>> verify which driver is in use, except maybe put a breakpoint. >>> >>> PS I had a quick look at the code [1]. It seems we are wired to >>> optionally accept Supplier<SSLContext> if the user binds one. This >>> would also be used with OkHttp according to the current impl. >>> >>> In other words, you can try this to manage your own ssl context on a >>> per-request basis. If you have luck doing this, then maybe we can >>> arrange a test case that replicates the scenario you discuss. >>> >>> .modules(ImmutableSet.of(new AbstractModule(){ >>> @Override public void configure() { >>> bind(new TypeLiteral<Supplier<SSLContext>>(){}).toInstance(new >>> Supplier<SSLContext>() { >>> @Override public SSLContext get() { >>> return whatYouManage; // note this is called per-request so >>> can be expensive. >>> } >>> } >>> } >>> })) >>> >>> [1] >>> https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L207 >>> >>> On Fri, Oct 3, 2014 at 10:05 AM, Yury Kats <[email protected]> wrote: >>>> Tried both, no change in behavior. >>>> >>>> However, what's confusing, is that if I add just the jclouds-okhttp jar, >>>> without pulling its dependencies (no okhttp and okio), >>>> I can still instantiate the KeystoneApi and connect >>>> >>>> KeystoneApi keystoneAPI = ContextBuilder.newBuilder(new >>>> KeystoneApiMetadata()) >>>> .endpoint(url) >>>> .credentials(tenant + ":" + user, key) >>>> .modules(ImmutableSet.of(new >>>> OkHttpCommandExecutorServiceModule())) >>>> .buildApi(KeystoneApi.class); >>>> >>>> Which makes me think the driver is not being utilized, regardless of the >>>> .modules() modifier. >>>> >>>> How can I confirm what driver is actually being used to make the >>>> connection? >>>> >>>> >>>> On 10/3/2014 12:44 PM, Adrian Cole wrote: >>>>> Nope that's it. Same process for the okhttp one (if you wish to try it) >>>>> >>>>> -A >>>>> >>>>> On Oct 3, 2014 9:15 AM, "Yury Kats" <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Thanks, got them. >>>>> >>>>> So to use those drivers, all I need to do is add >>>>> >>>>> .modules(ImmutableSet.of(new >>>>> ApacheHCHttpCommandExecutorServiceModule())) >>>>> >>>>> into >>>>> >>>>> KeystoneApi keystoneAPI = ContextBuilder.newBuilder(new >>>>> KeystoneApiMetadata()) >>>>> .endpoint(url) >>>>> .credentials(tenant + ":" + user, key) >>>>> .buildApi(KeystoneApi.class); >>>>> >>>>> Or is there more to it? >>>>> >>>>> On 10/3/2014 9:56 AM, Andrew Phillips wrote: >>>>> > Hi Yury >>>>> > >>>>> >> I don't seem to find those in any of the jclouds 1.8.0 jars. >>>>> >> Where do I get them from? >>>>> > >>>>> > They're additional dependencies with GA >>>>> > org.apache.jclouds.driver:jclouds-okhttp and >>>>> > org.apache.jclouds.driver:jclouds-apachehc [1] respectively. You >>>>> > should be able to add them to your project as just an additional >>>>> Maven >>>>> > dependency (if you're using Maven) - they'll take care of wiring >>>>> them >>>>> > up themselves. >>>>> > >>>>> > If you have any questions or it doesn't seem to work, please give us >>>>> > some more details about your project setup (e.g. are you using >>>>> Maven?). >>>>> > >>>>> > Regards >>>>> > >>>>> > ap >>>>> > >>>>> > [1] http://search.maven.org/#search%7Cga%7C1%7Cjclouds%20driver >>>>> > >>>>> >>>> >>> >>
