Avoid using shared resource streams between class loaders when extracting the native library. #578
Conversation
…ting the native library. This changes makes it so that we replace Class#getResoirceAsStream() with a custom method that finds the resources and creates a stream but disables caching the stream. This is necessary in environments with where the native library has to be extracted and used with multiple class loaders that get closed. Specifically, I was observing the following [JDK-8205976](https://bugs.openjdk.java.net/browse/JDK-8205976) in a [Gradle](https://gradle.org/) project with concurrent tasks that use sqlite-jdbc. The exact exception I was observing was: ``` java.io.IOException: Stream closed at java.base/java.util.zip.InflaterInputStream.ensureOpen(InflaterInputStream.java:68) at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:143) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252) at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:271) at org.sqlite.SQLiteJDBCLoader.contentsEquals(SQLiteJDBCLoader.java:179) at org.sqlite.SQLiteJDBCLoader.extractAndLoadLibraryFile(SQLiteJDBCLoader.java:243) at org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:344) at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:67) ``` Which lead me to JDK-8205976 after lots of logging. The test is a big complicated but sets ups the exact case for when this occurs. Multiple concurrent threads with isolated class loaders initializing the library for which the resource on all point to the same jar.
|
Hi @xerial - Sorry to ping you, but is there a chance you can take a look at this PR, would love for it to get merged if possible. Thanks! |
|
ok. I wasn't aware of this bug https://bugs.openjdk.java.net/browse/JDK-8205976. Let me check |
|
@xerial, just a friendly ping on this, hope you are well. Thank you! |
|
Looking forward to having this pull-request merged too, as it seems to be the reason why "Room" is not yet updating to sqlite-jdbc 3.34.0: https://issuetracker.google.com/issues/174695268#comment8 Due to this reason, projects using "Room" only compile on Android-Studio-Canary (for Apple Silicon / ARM) when using the workaround that is described in the issue linked above. |
|
Hi @xerial , sorry for pinging here again, is there any chance of merging this and releasing a new version? Let us know if we can help in any way. |
|
@xerial it would be of great help, if you could merge this pull request. Those with M1 are having a tough time. |
* Update sqlite-jdbc to 3.34.0 * Use a custom loader in Room instead of SQLiteJDBCLoader since it workarounds current issues in the loading strategy, specifically: xerial/sqlite-jdbc#578. Fixes: 177673291 Test: ./gradlew bOS Change-Id: Idc597b734bc4d7bc03ffe938d2306b31193ada27
|
Can this be merged? |
|
Yes. Thanks for waiting. I'll release 3.35.0 soon. |
This changes makes it so that we replace
Class#getResourceAsStream()with a custom method that finds the resources and creates a stream but disables caching the stream. This is necessary in environments with where the native library has to be extracted and used with multiple class loaders that get closed.Specifically, I was observing the following JDK-8205976 in a Gradle project with concurrent tasks that use sqlite-jdbc. The exact exception I was observing was:
Which lead me to JDK-8205976 after lots of logging. The test is a big complicated but sets ups the exact case for when this occurs. Multiple concurrent threads with isolated class loaders initializing the library for which the resource on all point to the same jar.