[CONTROLLER-1591] Make it possible to use LevelDB native binary installed by OS package manager, instead of the one bundled in leveldbjni-all Created: 06/Feb/17 Updated: 25/Jul/23 Resolved: 28/Feb/17 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Michael Vorburger | Assignee: | Unassigned |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||
| External issue ID: | 7742 | ||||||||
| Description |
|
Some downstream distributions (I know of at least one..) object to having native .so binaries bundled in Java JAR, such as the /META-INF/native//*/libleveldbjni.so in leveldbjni-all-1.8-odl.jar, and would prefer to be able to use a LevelDB native binary installed by OS package manager (e.g. RPM). The as-is way is convenient though as default, so this should be more like an option: e.g. a -D or a sep. Karaf feature or even just a fall-back built into leveldbjni - like if no suitable /META-INF/native///libleveldbjni.so found, then attempt to find and use a LevelDB native binary installed by OS package manager. |
| Comments |
| Comment by Michael Vorburger [ 06/Feb/17 ] |
|
I dug a little bit more into this today, and believe this would probably require a little bit of work upstream in leveldbjni, but not much - I can now see what would have to be done where how; here are some pointers, for another day: Background: ODL uses http://doc.akka.io/docs/akka/current/scala/persistence.html, which uses https://github.com/fusesource/leveldbjni/, which is "just" a Java wrapper (based on http://fusesource.github.io/hawtjni/) for https://github.com/google/leveldb ... Next step: https://github.com/fusesource/leveldbjni/issues/90 ? |
| Comment by Michael Vorburger [ 06/Feb/17 ] |
|
The point of this issue actually is less the "binary installed by OS package manager" part than the "an alternative to those bundled inside the leveldbjni-all JAR" ... Basically I think we need to be able to be more flexible re. how the LevelDB binaries are searched for, found, and loaded, and have ODL pick it up from the system... This would also help with issues such as Looking at https://github.com/fusesource/hawtjni/blob/master/hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java, which I've now found is what underlies this, it may actually already be possible to do this using system properties like -Dlibrary.leveldbjni.path=... (and perhaps -Dlibrary.leveldbjni.version=..), somehow (in a quick test, I wasn't able to get this working; e.g. -Dlibrary.leveldbjni.path=/lib64/libleveldb.so.1 does not work, because it then actually looks for /lib64/libleveldb.so.1/libleveldbjni.so ...) |
| Comment by Michael Vorburger [ 08/Feb/17 ] |
| Comment by Michael Vorburger [ 28/Feb/17 ] |
|
Closing this, because as detailed in https://github.com/fusesource//issues/90: (a) it turns out that IFF a libleveldbjni.so is available somewhere on the FS (outside of the JAR where it's embedded default), then leveldbjni Java code can already be made to use it via an e.g. -Dlibrary.leveldbjni.path=/tmp/ - I had tested that (using a leveldbjni unit tests, not ODL/Karaf, but I see no reason why this wouldn't work for ODL via a Karaf startup -D as well). (b) getting a new official RPM placing libleveldbjni.so into e.g. /lib64/ seems to be a bigger PITA than anticipated, due to the https://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI policy. |