Cache stops being written to when java.io.InterruptedIOException: thread interrupted

[snodnipper]

When requesting tens of files in separate threads, cancelling some results in an java.io.InterruptedIOException: thread interrupted exception that causes hasJournalErrors = true;.

Consequently, within private synchronized Editor edit(String key, long expectedSequenceNumber) the cache is no longer updated because of hasJournalErrors.

Once in this state I do not believe that rebuildJournal(); is called until the cache is reinitialized. I looked in journalRebuildRequired() but that does not consider the hasJournalErrors flag.

Perhaps I should guard against threads being cancelled that are writing to the cache? RFC.

[swankjesse]

@snodnipper are you calling Thread.interrupt() ? That's unexpected on threads performing HTTP requests with OkHttp. You should prefer Call.cancel() instead.

[swankjesse]

... or are you calling ExecutorService.shutdown() ?

[snodnipper]

thanks Jesse for getting back. I am going to have to check early next week - the calling code is proprietary, where I simply provided an adapter using okhttp. I am pretty sure it is just an ExecutorService with boolean cancel(boolean mayInterruptIfRunning = true).

Essentially, the use case is:

• user views a map which requests tens of map tiles (unique urls to cover visible map data)
• user zooms in or pans
• tiles scheduled for download but now outside of the visible area are cancelled.

I will try and provide some further feedback next week. Cheers!

[swankjesse]

Right now OkHttp doesn't do well with interrupted threads. If you can use Call.cancel instead, things will probably work better.

(And we should independently decide what to do about Thread.interrupt, if anything.)

[snodnipper]

So the logic of the software is pretty simple:

• ThreadPoolExecutor
• Runnable objects are submitted to the executor and the Future is stored in a map (URL -> Future)
• Futures are cancelled with cancel(true)

I resolved it quickly by using MapDB as the cache. I then discussed a few options with folk, e.g. letting writes continue with another thread / using write ahead logs etc. We didn't want to put too much effort in without at least checking in with you guys.

Given the above, I couldn't see a great place to use Call.cancel - the generic ExecutorService (within the external library) could be running anything to get data, such as reading straight from disk.

@schoenobates

[swankjesse]

@snodnipper got it. My guess is that Future.cancel() calls Thread.interrupt(), and OkHttp isn't prepared to deal with this.

[snodnipper]

added a crude project to demo the problem https://github.com/snodnipper/okhttp-issue1903-demo

[cre8ivejp]

Any updates?
This is still happening on the version 3.8.0

[yschimke]

Dupe of #1902, closing as won't fix.