0

Got a Java 1.8 app which calls out to a couple of json webservices with everything working just fine.

However, whilst changing the caching model for one of the services, I'm doing larger requests, so need to extend the timeout value, and I'm doing it per this question: How to set timeout in Retrofit library?

So I've created the OkHttp client, set it on my RestAdapter and the new timeouts are working just fine for the service I'm changing.

However... another completely unrelated service call in my app is now throwing 500 errors when it calls the service. If I remove the OkHttp dependency from my build.gradle file, the service works perfectly again - literally no code has changed, just the dependencies, so I'm assuming that this is some conflict between RetroFit and OkHttp (despite them both being built by the same guys).

Any ideas? Or is there an alternative client I can use in place of OkHttp to side-step the issue?

If it makes a difference, I'm using RetroFit 1.9.0 and OkHttp 2.7.0 (but I've tried a few different OkHttp versions).

Community
  • 1
  • 1
Webreaper
  • 509
  • 4
  • 18
  • Diff the raw http requests before/after adding the dependencies. Is it a server responding 500 or is hitting a problem internally? - What code is doing those unrelated requests? Retrofit as well? That might auto-detect presence of OKHttp and use the best http implementation available. Maybe you need to configure it to use the old http implementation by default or change something that worked accidentially in the other http implementation. – zapl Dec 23 '15 at 15:57
  • Thanks, all good ideas. I think you're right about RetroFit, but I believe the default implementation is to use OkHttp anyway, but not sure. The raw https request looks identical before and after, but I'll try digging a bit deeper into the request. I'll also see if there's a way to make it default back to the previous client! – Webreaper Dec 23 '15 at 17:43
  • 1
    If you explicitly configure Retrofit to use OkHttp, you can also configure OkHttp’s logging interceptor. My guess is that OkHttp is enabling some feature that your webserver can’t handle. Possibly gzip? You might be able to work around by adding a header like `Content-Encoding: identity`. – Jesse Wilson Dec 24 '15 at 00:55
  • That's the weird thing - explicitly configuring RetroFit to use OkHttp still breaks for the bad service, so I think you're right - there must be some feature that OK is using that's not compatible with the bad service. – Webreaper Dec 24 '15 at 08:42
  • So, doing this: RestAdapter.Builder().setClient( new UrlConnectionClient() ) makes it work again, by overriding the default usage of OkClient if it resides in the classpath. Main question now is whether I care enough to debug and find out why OkHttp actually broke it. :) – Webreaper Dec 24 '15 at 08:52
  • I believe it broke for reasons listed here: https://github.com/square/retrofit/issues/1149 Though it seems to have possibly been fixed (or at least worked around based upon the last entry for the code merge) but I have not yet tested that fix. I hope it does as I want to use Retrofit 2 on GAE – Rex Remus Feb 18 '16 at 18:43

0 Answers0