-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exclusive Cache Lock #8209
base: master
Are you sure you want to change the base?
Exclusive Cache Lock #8209
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good feature but I’d like a lot more integration tests before we put this into end users’ hands
|
||
private fun openCache(directory: okio.Path): Cache { | ||
return Cache(directory, 10_000, FileSystem.SYSTEM).apply { | ||
// force early LRU initialisation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m a bit torn on this. You don’t get a failure immediately; you get it eventually.
This is probably fine; this new feature is advisory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this currently works until it doesn't. Then it ends up as 40+ bugs raised.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't really do IO operations on the main thread, so this should always be the case.
Which reminds me, for SSL init on main thread #8248
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with ‘We can’t really do I/O operations on the main thread’, but I don’t agree that OkHttpClient is being initialized on the main thread. We’re an I/O library!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the dominant DI libraries will all be initializing OkHttp on the main thread. You have to do extra work to avoid that.
lockFile.toFile().createNewFile() | ||
val channel = FileChannel.open(lockFile.toNioPath(), StandardOpenOption.APPEND) | ||
|
||
checkNotNull(channel.tryLock()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m anxious that this is going to fail for reasons related to the host file system’s lack of support, and not because the file is positively locked.
Would it be horrible to probe the file system if a lock fails to see if EVERY lock is going to fail? Maybe we attempt to lock a file named with a random token or a timestamp? If that also fails we know it’s the file system’s fault?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A big +1 to okio solving this in a "Swanky" new API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I'm not blocked on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll need to think more about this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made an attempt. Let me know if it's suitable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the PR!
But I’m still anxious about how it’ll work on real-world file systems. We probably should confirm it does something reasonable on Mac, Windows, Linux and Android? (Why is this off-by-default on Android?)
Yep, next stage is forcing it through. I forget why it's not on Android, I'll enable again and see. Or comment for future self. |
OK, running ok on Android. Most tests failing validly since they don't close Cache instances with
I'll fix tonight. |
Excellent! |
Working on Windows, but tests are brittle :(
|
# Conflicts: # okhttp-dnsoverhttps/src/test/java/okhttp3/dnsoverhttps/DnsOverHttpsTest.kt # okhttp/build.gradle.kts # okhttp/src/commonJvmAndroid/kotlin/okhttp3/internal/cache/CacheLock.kt # okhttp/src/jvmTest/kotlin/okhttp3/CacheLockTest.kt # okhttp/src/jvmTest/kotlin/okhttp3/CacheTest.kt # okhttp/src/jvmTest/kotlin/okhttp3/LockTestProgram.java
Implement a strict CacheLock that works within the process, and also via file system locking if supported.
We can expect a bunch of failures in apps that aren't strictly using a single Cache instance, but should be.
Follow up to #8083