Re: [VuFind-Tech] alphabetic browse indexing: not finding SQLite library

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Thanks for sharing this!

Might be worth adding a note to the alphabrowse wiki page for other FreeBSD users...

- Demian

> -----Original Message-----
> From: Tod Olson [mailto:to...@uc...]
> Sent: Tuesday, May 28, 2013 11:47 AM
> To: Mark Triggs
> Cc: vuf...@li... Tech
> Subject: Re: [VuFind-Tech] alphabetic browse indexing: not finding SQLite
> library
> 
> Well, this becomes more complicated. Here's the upshot:
> 
> VuFind ships with the Xerial SQLite JDBC driver. It's an offshoot of the
> Zentus SQLite JDBC driver which bundles in the shared object code.
> Unfortunately, I couldn't build a working native version for FreeBSD.
> 
> FreeBSD has a port for the older Zentus SQLite JDBC driver, that's where
> sqlitejdbc-native.jar came from in the first place. My solution is to hack the
> index-alphabetical.sh script to include the Zentus driver if it is installed.
> That lets me run on FreeBSD but not screw up deployment on Linux.
> 
> I doubt this is of sufficiently broad interest to merge it into the base code.
> 
> -Tod
> 
> 
> On May 20, 2013, at 9:31 PM, Tod Olson <to...@uc...> wrote:
> 
> > Right! sqlitejdbc-native.jar repeats 12 classes in the sqlite-jdbc-3.7.15-
> SNAPSHOT.jar. So I'll try stacking the order when I get into the office and
> see how it goes.
> >
> > Thanks!
> >
> > -Tod
> >
> >
> > On May 20, 2013, at 4:11 PM, Mark Triggs <ma...@di...>
> > wrote:
> >
> >> Hi Tod,
> >>
> >> What's the difference between sqlitejdbc-native.jar and
> >> sqlite-jdbc-3.7.15-SNAPSHOT.jar here?  Is there any overlap to the
> >> classes those .jar files provide?
> >>
> >> Does it make a difference if you force the jar files to load in a
> >> particular order?  Any difference between:
> >>
> >> java -Dfile.encoding=UTF-8 -cp '../solr/lib/sqlitejdbc-
> native.jar:../solr/lib/sqlite-jdbc-3.7.15-SNAPSHOT.jar:browse-indexing-multi-
> title.jar:../solr/lib/*' CreateBrowseSQLite sorted-title.tmp title_browse.db
> >>
> >> versus:
> >>
> >> java -Dfile.encoding=UTF-8 -cp '../solr/lib/sqlite-jdbc-3.7.15-
> SNAPSHOT.jar:../solr/lib/sqlitejdbc-native.jar:browse-indexing-multi-
> title.jar:../solr/lib/*' CreateBrowseSQLite sorted-title.tmp title_browse.db
> >>
> >> that?
> >>
> >> I'm just thinking that the '../solr/lib/*' wildcard probably adds jars
> >> to the classpath in inode order, and that's the sort of thing that could
> >> vary between machines.
> >>
> >> Cheers,
> >>
> >> Mark
> >>
> >>
> >> Tod Olson <to...@uc...> writes:
> >>
> >>> vufind-tech,
> >>>
> >>> I have a problem with one machine that's unable to create the SQLite
> indexes because the browse-indexer can't find the SQLite code. The problem is
> unique to this host, other local are building the browse indexes just fine.
> The jar file being executed is a local version of the browse indexer, and it
> worked just fine on this host a few weeks ago. Clearly something has changed
> on this host, but I've been unable to identify what, so I turn to the list.
> >>>
> >>> Here's the failure message that we see on the one host:
> >>>
> >>> diamond% java -Dfile.encoding=UTF-8 -cp 'browse-indexing-multi-
> title.jar:../solr/lib/*' CreateBrowseSQLite sorted-title.tmp title_browse.db
> >>> Exception in thread "main" java.sql.SQLException: Error opening connection
> >>> 	at org.sqlite.Conn.open(Conn.java:165)
> >>> 	at org.sqlite.Conn.<init>(Conn.java:87)
> >>> 	at org.sqlite.JDBC.createConnection(JDBC.java:113)
> >>> 	at org.sqlite.JDBC.connect(JDBC.java:87)
> >>> 	at java.sql.DriverManager.getConnection(DriverManager.java:620)
> >>> 	at java.sql.DriverManager.getConnection(DriverManager.java:222)
> >>> 	at CreateBrowseSQLite.create(CreateBrowseSQLite.java:128)
> >>> 	at CreateBrowseSQLite.main(CreateBrowseSQLite.java:154)
> >>> Caused by: java.lang.Exception: Error loading native library:
> /org/sqlite/native/FreeBSD/amd64/libsqlitejdbc.so
> >>> 	at
> org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:241)
> >>> 	at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:63)
> >>> 	at org.sqlite.NativeDB.load(NativeDB.java:50)
> >>> 	at org.sqlite.Conn.open(Conn.java:161)
> >>> 	... 7 more
> >>>
> >>> Can't find the SQLite native library code, that seems straightforward.
> >>>
> >>> On successful host magma, truss shows that java finds the SQLite JDBC and
> native object code here:
> >>>
> >>> 	/data/magma/vufind2/solr/lib/sqlitejdbc-native.jar
> >>> 	/data/magma/vufind2/solr/lib/sqlite-jdbc-3.7.15-SNAPSHOT.jar
> >>> 	/usr/local/lib/libsqlitejdbc.so
> >>> 	/usr/local/lib/libsqlite3.so.8
> >>>
> >>> These files all exist on the unsuccessful host, with the same checksums.
> Same for browse-indexing-multi-title.jar. So both hosts have the same object
> code. Java is at the same version, OpenJDK Runtime Environment (build
> 1.6.0_32-b27).
> >>>
> >>> What _is_ different is that on the unsuccessful host, according to truss:
> >>>
> >>> 1. java opens the sqlite jar files in the opposite order, and
> >>> 2. _never_ stats for libsqlitejdbc.so.
> >>>
> >>> That second bit is what gets me. The successful host stats for the shared
> object file in the various java and system libraries, the unsuccessful host
> NEVER call stat() or access() or in any way looks for libsqlitejdbc.so.
> >>>
> >>> Looking at the dynamic linking on both systems, LD_LIBRARY_PATH is not
> set, setting it does not seem to make a difference, and both systems list
> /usr/local/lib in "search directories" /var/run/ld-elf.so.hints. So I _think_
> that the load library configuration is _not_ to blame here.
> >>>
> >>> So what does that leave? Some conditional in the Java code? a config file
> I'm not thinking of? I'm almost tempted to walk through the command-line
> debugger, so any ideas would be most welcome.
> >>
> >> --
> >> Mark Triggs
> >> <ma...@di...>
> >
> 
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Vufind-tech mailing list
> Vuf...@li...
> https://lists.sourceforge.net/lists/listinfo/vufind-tech