You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Manuel Albela Miranda <al...@3.14financial.com> on 2006/12/01 08:04:05 UTC
Re: Solr, new index format (segments_N)
Yonik Seeley wrote:
> UnsatisfiedLinkError means that the JVM can't find a native method,
> and Solr and Lucene have no native methods. Something else is
> probably messed up...
>
> Try building and running Solr with the supplied lucene jar first, to
> make sure you have the process down correctly. Once that works, then
> try moving to the latest lucene jars.
>
> -Yonik
>
Hey Yonik,
Yes, i've tried that. Building and running Solr with the supplied jar
works ok, the problem raises when i copy the latest lucene jar. It has
to be with the created lucene .jar, but i don't know why...
Regards.
Manu.
Re: Solr, new index format (segments_N)
Posted by Manuel Albela Miranda <al...@3.14financial.com>.
Chris Hostetter wrote:
> : Now i have solr working with lockless index, but i had to download the
> : binaries from the lucene website so now it works ok, but still don't
> : know why the jar file generated in the compilation of the lucene svn
> : sources doesn't work with solr, so the main part of the problem is
> : solved, i will go on investigating why the compiled jar doesn't work, bu
> : i think it's no a java problem, in that case it won't work even with the
> : lucene binaries.
>
> if the lucene jars built by someone else work, but the jars you compile
> for yourself don't then that suggests to me that there is an
> incompatibility between the java compiler you are using to compile the
> code, and the JVM you are using hte run the code ... is there any
> possibility you have a 1.6 javac lying arround that might be getting used
> by ant?
>
>
>
> -Hoss
>
>
>
> .
>
>
I don't think so, the output when i run javac -version is the next:
javac -version
javac 1.5.0_06
javac: no source files
Usage: javac <options> <source files>
where possible options include:
-g Generate all debugging info
-g:none Generate no debugging info
-g:{lines,vars,source} Generate only some debugging info
-nowarn Generate no warnings
-verbose Output messages about what the compiler is
doing
-deprecation Output source locations where deprecated
APIs are used
-classpath <path> Specify where to find user class files
-cp <path> Specify where to find user class files
-sourcepath <path> Specify where to find input source files
-bootclasspath <path> Override location of bootstrap class files
-extdirs <dirs> Override location of installed extensions
-endorseddirs <dirs> Override location of endorsed standards path
-d <directory> Specify where to place generated class files
-encoding <encoding> Specify character encoding used by source files
-source <release> Provide source compatibility with specified
release
-target <release> Generate class files for specific VM version
-version Version information
-help Print a synopsis of standard options
-X Print a synopsis of nonstandard options
-J<flag> Pass <flag> directly to the runtime system
then, i don't know what happens with the compilation.
Regards.
Manu.
Re: Solr, new index format (segments_N)
Posted by Chris Hostetter <ho...@fucit.org>.
: Now i have solr working with lockless index, but i had to download the
: binaries from the lucene website so now it works ok, but still don't
: know why the jar file generated in the compilation of the lucene svn
: sources doesn't work with solr, so the main part of the problem is
: solved, i will go on investigating why the compiled jar doesn't work, bu
: i think it's no a java problem, in that case it won't work even with the
: lucene binaries.
if the lucene jars built by someone else work, but the jars you compile
for yourself don't then that suggests to me that there is an
incompatibility between the java compiler you are using to compile the
code, and the JVM you are using hte run the code ... is there any
possibility you have a 1.6 javac lying arround that might be getting used
by ant?
-Hoss
Re: Solr, new index format (segments_N)
Posted by Manuel Albela Miranda <al...@3.14financial.com>.
Chris Hostetter wrote:
> : Yes, i've tried that. Building and running Solr with the supplied jar
> : works ok, the problem raises when i copy the latest lucene jar. It has
> : to be with the created lucene .jar, but i don't know why...
>
> looking back at your stack trace, my gut instinct is that there is
> something wrong with your java setup, such that the native code libraries
> used to impliment the system classes (specificly the regex functionality)
> aren't linked properly (or some other crazy DLL/so mumbojumbo) and you
> only get the problem with the lockless commits version because thats when
> it started using pattern matching on file names.
>
> ...except that as far as i can tell the old version would used pattern
> matching too, just not as much. .. hmm, acctually, i take that bcak: the
> code to call String.matches to determine what files are part of the
> index was there, but i don't acctual see it getting used -- at least not
> in the code from your stack trace (opening an index)
>
> thinking about it a bit: before lockless commits there really was only one
> purpose for the IndexFileNameFilter, removing all "index" files from a
> directory when asked to create a new index ... code that Solr never would
> have executed (i don't believe) ... so maybe that is the problem?
>
> Manuel: forget about Solr for a minute, when you compile the Lucnee trunk,
> can you run the (Lucene) tests successfully ?
>
> more importantly: does the commandline Lucene demo work for you? can you
> run...
>
> java org.apache.lucene.demo.IndexFiles [somepath]
>
> ...if i'm write, that will fail if you run it more then once in the same
> directory (so that an "index" directory with stuff in it has already been
> created when you run it a a second time) ... it should even fail with the
> lucene 2.0 release.
>
> (hell: if i'm right, a 1 line hello world class you write that just calls
> System.out.println("string".matches("\\d")) would fail the same way)
>
>
>
> -Hoss
>
>
>
>
>
Hi Chris,
Now i have solr working with lockless index, but i had to download the
binaries from the lucene website so now it works ok, but still don't
know why the jar file generated in the compilation of the lucene svn
sources doesn't work with solr, so the main part of the problem is
solved, i will go on investigating why the compiled jar doesn't work, bu
i think it's no a java problem, in that case it won't work even with the
lucene binaries.
Thank you for your time.
Regards.
Manu
Re: Solr, new index format (segments_N)
Posted by Chris Hostetter <ho...@fucit.org>.
: Yes, i've tried that. Building and running Solr with the supplied jar
: works ok, the problem raises when i copy the latest lucene jar. It has
: to be with the created lucene .jar, but i don't know why...
looking back at your stack trace, my gut instinct is that there is
something wrong with your java setup, such that the native code libraries
used to impliment the system classes (specificly the regex functionality)
aren't linked properly (or some other crazy DLL/so mumbojumbo) and you
only get the problem with the lockless commits version because thats when
it started using pattern matching on file names.
...except that as far as i can tell the old version would used pattern
matching too, just not as much. .. hmm, acctually, i take that bcak: the
code to call String.matches to determine what files are part of the
index was there, but i don't acctual see it getting used -- at least not
in the code from your stack trace (opening an index)
thinking about it a bit: before lockless commits there really was only one
purpose for the IndexFileNameFilter, removing all "index" files from a
directory when asked to create a new index ... code that Solr never would
have executed (i don't believe) ... so maybe that is the problem?
Manuel: forget about Solr for a minute, when you compile the Lucnee trunk,
can you run the (Lucene) tests successfully ?
more importantly: does the commandline Lucene demo work for you? can you
run...
java org.apache.lucene.demo.IndexFiles [somepath]
...if i'm write, that will fail if you run it more then once in the same
directory (so that an "index" directory with stuff in it has already been
created when you run it a a second time) ... it should even fail with the
lucene 2.0 release.
(hell: if i'm right, a 1 line hello world class you write that just calls
System.out.println("string".matches("\\d")) would fail the same way)
-Hoss