Allow for container usage where libraries/plugins may use OkHttp internally and it's not clear who cleans up. This brings HTTP/2 inline with the daemon only behaviour of HTTP/1.1.
This removes a bunch of low-value stuff from the pom.xml files:
- name
- description
- licence distribution ('repo')
- developers clause
- test dependencies
I don't think any of this will be missed, and it shrinks the pom.xml
file to the minimal set of useful stuff.
This also causes us to publish a gradle .module file. This is the
motivation for this change. It'll allow us to ship a Gradle platform,
which is a more capable than a Maven BOM.
The new ktlint sorts imports which makes this diff large.
The new japicmp ignores 'final' modifier changes in final classes.
We adopt the Google style for checkstyle.xml.
Okio readByteString() now uses segments more aggressively, so we
need to mitigate that to avoid tracking those segments in a test.
The problem was the awaitIdle() call was scheduling executor jobs after
the ExecutorService had been shut down. This fixes that and defends
against other races.
This changes the timing of responseHeaderStart and responseBodyStart events to
fire when bytes are received from the server. This is a non-trivial behavior
change and should be documented as such in the release notes. In particular,
the responseFailed event may be fired without a preceding responseHeadersStart
event.
To test this I've added a timestamp to our CallEvent test facet.
Closes: https://github.com/square/okhttp/issues/5578
This is based roughly on the 'Degraded Connections' proposal here
https://github.com/square/okhttp/issues/3146#issuecomment-471196032
I'm using 1000 ms instead of 500 ms. That's about the cost of a (slow)
TLS handshake, which is what callers would need to do if we degrade
unnecessarily.
This was a regression introduced with the TaskRunner changes.
I couldn't find other places where daemon threads were likely
to cause potential problems.
https://github.com/square/okhttp/issues/5512
This probably should have been the case all along. Unfortunately,
ExecutorService Runnables are not cancelable by default, and that's
where we started.
After implementing all of TaskRunner it looks like where we're
cancelable and where we aren't is totally arbitrary. Making everything
cancelable simplifies the implementation and model.
The last remaining non-cancelable tasks:
* awaitIdle() which we use in our tests only.
* MockWebServer, where canceling would leak sockets
Examples:
- OkHttp TaskRunner
- MockWebServer TaskRunner
- OkHttp ConnectionPool
- MockWebServer localhost applyAndAckSettings
- OkHttp android.com applyAndAckSettings
- OkHttp android.com onSettings
- OkHttp awaitIdle
- OkHttp localhost
I'm trying to use type names where appropriate, or method names otherwise.
Names include hostname and stream name if the task is working on behalf
of a specific stream or connection.
Now we don't have to alternate between the coordinator thread and the task
thread between task runs if the task returns 0. Instead the task thread can
stay resident.
This implementation works by having task runnables that can switch from
the coordinator role (sleeping until the next task starts) and the executor
role.
https://github.com/square/okhttp/issues/5512
It now tracks inbound requests that fail with an IOException.
Also add a fix for the bug where we'd send 'END OF STREAM' on a stream
that we'd previously canceled, which raced with the 'RST STREAM' and led
to flakiness.
Before we ship the new API in RecordedRequest we should go over the
other cases where inbound HTTP requests fail and make sure they
get reported through this channel.
Closes: https://github.com/square/okhttp/issues/5388
* Name tasks only in TaskRunner
Naming queues seemed good initially, but the names are mostly
mutually-redundant with task names.
This PR reduces debug information when a queue is still busy
when the test completes. I have a fix for that in a follow-up
change.
* Update okhttp/src/main/java/okhttp3/internal/ws/RealWebSocket.kt
Co-Authored-By: Yuri Schimke <yuri@schimke.ee>
The most consequential change here is that the background thread is
now a daemon thread. A program consisting of exactly one web socket
will exit when the reader reads an inbound close message. Previously
such a program would continue running until the writer acknowledged
this close.
Shutting down queues makes it easier to implement HTTP/2
shutdown because we can enqueue everywhere and centralize
the logic that decides whether we're shutdown or not.
Use this new functionality to implement HTTP/2 on task queues.
It's mostly a drop-in replacement, though opting-into cancel
looks like a mistake when it's what we do most of the time.
When testing this the OkHttpClientTestRule was failing because
tasks were incomplete. I was puzzled by this until I realized
that the OkHttpClientTestRule performs that validation before
we stop the MockWebServer. I changed MockWebServer to have its
own TaskRunner and that made the problem go away.
