As originally designed DiskLruCache assumes an inode-like
file system, where it's fine to delete files that are
currently being read or written.
On Windows the file system forbids this, so we must be
more careful when deleting and renaming files. These
operations come up a lot internally in the cache:
- deleting to evict an entry
- renaming to commit a dirty file to a clean file
The workaround is simple if unsatisfying: we don't
permit concurrent reads and writes on Windows. We
can have multiple concurrent reders, or a single
writer.
One challenge in this implementation is detecting
whether we're running on Windows or a good operating
system. We deliberately don't look at System properties
here because the OS and file system may disagree, such
as when a Windows machine has an ext4 partition, or when
a Linux machine has an NTFS partition. Instead of detecting
we just attempt an edit and see what happens.
Another challenge in this implementation is what to
do when a file needs to be deleted but cannot be because
it is currently open. In such cases we now mark the
cache entry as a 'zombie'. When the files are later
closed they now check for zombie status and delete the
files if necessary. Note that it is not possible to
store a new cache entry while it is a zombie.
Closes: https://github.com/square/okhttp/issues/5761
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
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>
We used to do this lazily because OkHttpClient instances were
somewhat heavy: each standalone instance held its own
ExecutorService for the connection pool.
Now that we have TaskRunner each instance is much more
lightweight and the drawbacks of creating instances eagerly
is negligible.
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.
