| 715f88092afc34bbe129118fa9ed737ad38ec050 |
|
24-Jan-2017 |
Tobias Thierer <tobiast@google.com> |
OkHttp quick fix: canceled StreamAllocations can never recover
When a HttpURLConnection is disconnected in the middle of connecting,
this can lead to an infinite loop because:
- StreamAllocation.findConnection() immediately throws
(before advancing the RouteSelector)
- StreamAllocation.recover() returns true, indicating that a
retry is permissible
- higher level logic then retries the connection indefinitely in
a busy loop
This bug does not occur in the latest version of OkHttp (3.5) but
can be reproduced directly on top of OkHttp 2.7.5.
To give us more time to figure out the best fix, this CL makes the
narrowest possible fix for the concrete behavior observed in the wild.
There are related cases where StreamAllocation.recover() returns true
but findConnection() immediately throws; these have not been observed
and are not addressed by this CL:
- StreamAllocation.released; this case looks at first glance like it
is not reachable via publicly exposed API (HttpURLConnection)
- canceled case for recover(IOException e, Sink requestBodyOut):
touching this breaks OkHttp's
CallTest.canceledBeforeIOSignalsOnFailure*() because the reported
error message becomes something like "Socket closed", rather
than reviewed "Canceled".
Test: CtsLibcoreTestCases
Test: CtsLibcoreOkHttpTestCases
Bug: 33763156
Change-Id: Ie8e80559f9364cbd0a01c54b441fc10402b37862
/external/okhttp/okhttp/src/main/java/com/squareup/okhttp/internal/http/StreamAllocation.java
|
| 6c251e20f00c7574b217bd4351ac81666f574380 |
|
24-Jun-2016 |
Tobias Thierer <tobiast@google.com> |
Update OkHttp to 2.7.5 and advance okio by one commit.
This brings OkHttp and okio exactly in line with upstream commits
with no local changes.
Corresponding upstream commits:
okhttp:6e236ce3b80f21369dc544f0e1053ff71be8689b (= parent-2.7.5)
okio: 02481cc0cc84bc92e3eab6d5212a226496f56a7e
The okio commit differs from the one in the previous pull from
Sep 2015 (AOSP commit 71b9f47b26fb57ac3e436a19519c6e3ec70e86eb)
only by a single upstream commit, the switch to 8 KiB segments.
That commit was previously cherry-picked in AOSP. This CL will
temporarily revert the AOSP changes to okio, but those
AOSP changes to okio will be reapplied in the subsequent CL.
Compilation and tests do not pass after this CL, they will only
pass at the end of the chain of 11 CLs going in at the same time.
9 of these 11 CLs are in external/okhttp, the others affect
libcore and frameworks/base.
Details of behavioural changes introduced by this upgrade are at:
https://docs.google.com/document/d/19PF3Exd_q32gAGCiRFWRf0Pq_xrIWs-cRViHkFTxJg8/edit
This CL includes files that are not used in Android, such as
- top level dot files (.travis.yml etc.)
- subdirectories okurl, okhttp-apache, samples, which aren't used
- tests in okhttp-hpacktests, okhttp-ws-tests that aren't run
or test functionality that we aren't used
Test: I've run the following tests *at the end* of the chain of
commits, in cts-tradefed:
1.) run cts -p android.core.tests.libcore.package.harmony_java_net
2.) run cts -c libcore.java.net.URLConnectionTest
3.) run cts -p android.core.tests.libcore.package.okhttp
4.) run cts -p android.core.tests.libcore.package.libcore
1.-3.) all passed
4.) had 24 unrelated failures per b/29496407 and b/29744850
Change-Id: Id798d6cf49fa4a7a4ab8ae3b699a38104bf42db3
/external/okhttp/okhttp/src/main/java/com/squareup/okhttp/internal/http/StreamAllocation.java
|