Hi, Ignasi. Well main thing is that OkHttp allows you to programmatically control properties and state otherwise done with system properties or static variables. This includes the keepalive pool, etc. Starting with v2, it has a native api which isn't required to be portable with the flaws in HttpUrlConnection. I think the most gain is here. Moreover, there are some apis which follow rfc complaint caching more or less. In such case we use that, one would want to configure where the cache writes, etc.
Good point about there probably being apis that even okhttp can't help. I vote for naming and shaming until they change ;) -A On Oct 3, 2014 2:46 PM, "Ignasi Barrera" <n...@apache.org> wrote: > Regarding OkHttp driver tuning, it has a lot of room for improvement! :) > It was added to allow APIs such as OpenStack Marconi to use the PATCH verb > in HTTP requests and AFAIK it is currently only used there for that purpose. > > It would be awesome to have some known best practices and recommended > configurations so we can improve the driver and make it more customizable! > > I've also found some providers that don't work with it because they send > GET requests with a body and/or other bad practices (don't remember exactly > if the GET example was the one I found, but you get the idea; OkHttp > forbids some of those) so keep ot in mind. > El 03/10/2014 21:06, "Adrian Cole" <adrian.f.c...@gmail.com> escribió: > >> Plus, if you are using google storage, it will automatically use SPDY :P >> >> On Fri, Oct 3, 2014 at 12:05 PM, Adrian Cole <adrian.f.c...@gmail.com> >> 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 <yuryk...@yahoo.com> 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 <yuryk...@yahoo.com> >> 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" <yuryk...@yahoo.com <mailto: >> yuryk...@yahoo.com>> 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 >> >>>>> > >> >>>>> >> >>>> >> >>> >> >> >> >
