Sometimes we name a thread both via its ExecutorService
and via a NamedRunnable. The ExecutorService thread needs
to be named because threads are cached and will be visible
in a thread dump even when no runnables are running.
NamedRunnables are also used because they provide additional
context: the host or URL being serviced by a thread.
Previously we were assuming a field initializer wouldn't be
run until after the constructor. It wasn't and we were getting
NullPointerExceptions looking up the bufferPool.
Re-using buffers can help avoid GC and make things run more smoothly when streaming data.
squash! Use AOSP ByteArrayPool to try and avoid buffer GC.
Copy tests over and attempt at better formatting.
squash! Use AOSP ByteArrayPool to try and avoid buffer GC.
ArrayDeque is <= API level 9 :-(
squash! Use AOSP ByteArrayPool to try and avoid buffer GC.
Another attempt at formatting.
fixup! squash! Use AOSP ByteArrayPool to try and avoid buffer GC.
Indent code properly attempt.
Now that Request and Response self-describe, I think the
word Headers is sufficient. And it's a lot less ugly than
RawHeaders.
Also move header serialization code to HttpTransport and
SpdyTransport.
This breaks support for java.net.ResponseCache implementations. That's
good. That API is akward and can't support important features like
conditional GETs and hit tracking.
I needed a non-terrible way to provide the HTTPS handshake
information to the async API. Previously we were passing the
live socket around, which was leaky and gross.
This creates a new value object that captures the relevant
bits of the handshake. We can use it in the response, the
connection, and also in the cache. It's plausible that in
the future we can use it to allow the application to block
requests if the handshake is insufficient.
This notably allows the mockwebserver project to be run on Android.
ServerSocket only implements Closeable since Java 1.7 and thus calling of
closeQuietly(Closeable) with a ServerSocket argument fails when running
on Java 1.5 or 1.6 JVMs. This is the same as is already done for
closeQuietly(Socket).
This was causing some SPDY connections to be evicted early,
and preventing connection reuse.
The spdyConnectionReuse test becomes flaky with the
fix that makes MockWebServer use different sequenceNumbers
for different requests on the same socket. With the fix
the test is no longer flaky. The old test wasn't good enough
to detect what it wanted to detect!
This race has existed in the code since we added more
aggressive time-based expiration in January 2013. In my
basic tests the race impacted ~20% of connections on a
desktop VM. It may have been more on mobile.
This is closer to the semantics of HTTP/2.0, which uses the HEADERS
frame for all three types. SPDY is a bit more strict because it
relies on redundancy; it's an error to send a SYN_REPLY after a
HEADERS frame. With HTTP/2.0, there's only one type so there's
no error to detect.
