I'm currently keeping these as longs. That's easy an unambiguous, but it also
feels rather primitive.
This was more work than I expected, but it doesn't seem particularly risky.
It's also potentially more efficient, since there's fewer places where we're
converting from string to long and vice versa.
Closes: https://github.com/square/okhttp/issues/2035
Avoid using System.out.
Use the best logging implementation on the host platform. On Java this is
java.util.logging. On Android it's Android.util.Log.
Closes https://github.com/square/okhttp/issues/2505
Still some work to do on method naming, but this was the interesting part.
Also very much need to rename OkUrlFactory in tests to urlFactory, otherwise
the client.client stuff becomes madness.
Instead each new instance of OkHttpClient gets its own connection pool by
default. This makes the OkHttpClient instances a little more heavyweight
(in that two different instances yield two different connection pools, which
means two different cleanup threads) but it also means there's less weird
state sharing between instances.
One drawback of this is that if an application wants to immediately free
resources from an OkHttpClient it must call getConnectionPool().evictAll(),
otherwise the connection pool thread will remain alive for 5 minutes.
Add the URL to the HTTP response when it is logged in the same manner
that the URL is added to the request logging. The added logging adds
some additional clarity when reading logs that contain many
request/response pairs.
There's a few places where OkHttp could leak a connection that needed to be
closed. With our new connection pool model this is easier to find. This fixes
two specific problems:
- too many redirects doesn't release the last used connection
- interceptors that throw runtime exceptions don't release the connection
There are likely more situations. I have hacked together a small little test
harness to make finding these leaks easier; that's not included in this PR.
Also formalize HttpURLConnection-only 'Response-Source' synthetic header to be on par with the protocol header (which is retained for this legacy interface).
