Skip to content

Fallback to in-memory db files - #69

Open
kares wants to merge 4 commits into
discourse:mainfrom
kares:in-memory
Open

kares wants to merge 4 commits into
discourse:mainfrom
kares:in-memory

Conversation

@kares

@kares kares commented Sep 28, 2026

Copy link
Copy Markdown

This is an attempt to properly resolve a JRuby specific issue: #37

which concerns traditional (Java) deployments, where source of them gem and thus this gem's DB files end up in a zip archive (.jar or .war).

While the issue is JRuby specific, it's unlikely an approach of fixing seek+pread for such scenarios would be the optimal path, seems much better to just fallback to read-ing the files in-memory.

@headius

headius commented Sep 30, 2026

Copy link
Copy Markdown

I have implemented an alternative fix for future versions of JRuby that will fully read jar resources into a separate buffer and make that buffer available as a seekable IO. It's basically the same as this PR but done internally in JRuby directly against an eagerly-read buffer.

jruby/jruby#9752

My criteria for fully reading is that it must be a jar:file URL, indicating that it is a resource from a local jar file and likely ok to fully read into memory (loading the jar and accessing the resource will do some amount of this anyway). It does mean the contents of the resource may be doubled-up in memory (compressed in the loaded jar, uncompressed in the eager buffer) but I think that's an acceptable trade-off to make files embedded in a jar appear to be more "normal".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants