Relay. This is a single entry in the upcoming DiskLruCache2.

[swankjesse]

At the moment there are some things still incomplete:

• Timeouts. Not yet tested, and no great implementation plan.
• Thread interrupts. This has been quite problematic for
  the original DiskLruCache. We should test and support this
  in Relay.
• File system problems. If the host file system is full or not
  accepting writes, we should fallback gracefully. This may
  be difficult.
• Metadata updates. At the moment the metadata is permanent
  and immutable.

That said, many nice features are already implemented:

• Metadata and stream data in one file.
• No locks held during file I/O or network I/O.
• Read from the buffer, the file, or the socket in that order.
• Reference counting on open sources. It is assumed that the
  creator of each Relay will take a source, and that guarantees
  that the count will always reach 0.

[dave-r12]

Nice

[dave-r12]

I'm still absorbing some bits and pieces but the logic is straightforward given the problem this is solving. Good stuff.

[swankjesse]

After a tiny amount of soul searching I decided what to do about timeouts. I’ll do the work in a follow up PR.

Whenever a thread reads from upstream it’ll first configure upstream’s timeouts from its own timeouts. So if a thread has a 3 second timeout it’ll use that to read upstream, even if other waiting threads have longer or shorter timeouts.

I figure this is pretty reasonable because in practice all of the threads in the same HTTP client reading the same resource will inevitably have the same timeouts anyway.

[dave-r12]

Any reason to hold this one up? LGTM.

[swankjesse]

I pitched this design to Jake before I wrote the code so I’m hoping to get his eyes on it too. He’s been tied up but should be back soon.

[JakeWharton]

lgtm. this is dense. had to give it two passes.

[swankjesse]

Yeah! More exciting stuff to come. Thanks @dave-r12 and @JakeWharton for the reviews!