: Hi Brian, all you have to do is create a logging.properties file and
: call this before starting up solr:
:
: System.setProperty("java.util.logging.config.file", home+"/conf/
: logging.properties");
it's not neccessary to execute any javacode to configurate
java.util.logging ... that property c
: Lucene boosts are per-field (not per-field-value) for a particular
: document, so you can't have a multi-valued field with some values
: boosted higher than others.
this little bit of subtlety in Lucene terminology has always bugged me ...
the way i like to think of it is that field boosts are
Chris Hostetter wrote:
: I almost didn't notice the exception fly by because there's s much
: log output, and I can see why I might not have noticed. Yay for
you should be able to configure it to put WARNING and SEVERE messages in a
seperate log file even.
Certainly! I learned to r
On 3/3/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 3/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> But MANY of the SolrExceptions use a status
> code '1'.
Hmmm, I did an audit of the exceptions before we entered the incubator, and
I thought I caught all the ones that generated anything out
On 3/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
But MANY of the SolrExceptions use a status
code '1'.
Hmmm, I did an audit of the exceptions before we entered the incubator, and
I thought I caught all the ones that generated anything out of the 400
and 500 range
and could be thrown during a
For anyone not on the dev list, I just posted:
http://issues.apache.org/jira/browse/SOLR-179
so it is not lost, I also posted Otis' bug report:
http://issues.apache.org/jira/browse/SOLR-180
/update
does send 200 even if there was an error.
after SOLR-173 we may want to change the default solrconfig to map
/update so that everything has a consistent error format.
On 3/3/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 3/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> Is there enou
On 3/3/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 3/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> Is there enough general interest in having error response codes to
> change the standard web.xml config to let the SolrDispatchFilter
> handle /select?
/select should already use HTTP error c
: I figured out my problem. My own jar must be in the examples/solr/lib
: directory (which does not exist in the download). I found a hint to
: this on the mailing list. The docs don't indicate this anywhere
: promenant. Perhaps the lib directory should exist in the default
: download in the f
On 3/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Is there enough general interest in having error response codes to
change the standard web.xml config to let the SolrDispatchFilter
handle /select?
/select should already use HTTP error codes, right?
-Yonik
There still may be a bug that Ryan mentioned about unknown fields
simply being ignored, but that should be fixed if true.
I just looked into this - /trunk code is fine.
I wasn't noticing the errors because the response code is always 200
with an error included in the xml. My code was only ch
: Right now, Solr accesses the DOM as needed (at runtime) to fetch
: information. There isn't much up-front checking beyond the XML
: parser.
bingo, and adding more upfront checking is hard for at least two reasons i
can think of...
1) keeping a DTD up to date is a pain sa new features are added
: > I spent a long time tracking down an error with a document set with an
: > uppercase field name to something configured with a lowercase field.
: Isn't this the kind of error that XML validation is supposed to address?
it could be ... except that:
1) we can't using standard DTD/XSD style v
: I almost didn't notice the exception fly by because there's s much
: log output, and I can see why I might not have noticed. Yay for
: scrollback! (Hrm, I might not have wanted to watch logging for 4
: instances of solr all at once. Might explain why so much logging.)
FYI: Solr logs a lot o
On 3/3/07, Jed Reynolds <[EMAIL PROTECTED]> wrote:
If dynamicField definitions are removed from the schema.xml file (and
your fields are not referencing them), does this have the same effect of
disabling unknown-field generation?
Yes. You should get an error if you add a document with a field
Yonik Seeley wrote:
On 3/2/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
How do you all feel about returning an error when you add a document
with unknown fields?
+1
dynamicField definitions can be used if desired (including "*" to
match every undefined field).
If dynamicField definitions ar
Yonik Seeley wrote:
On 3/3/07, Dimitar Ouzounov <[EMAIL PROTECTED]> wrote:
But what hardware problem could it be? Tomorrow I'll make sure that the
memory is fine, but nothing
else comes to my mind.
Memory, motherboard, etc.
Try http://www.memtest86.com/ to test this.
It may be OS-related - p
sweet.
the logging is java logging... (not one i really know how to deal with)
Can you try setting system property like this:
http://www.exampledepot.com/egs/java.util.logging/Props.html
Brian Whitman wrote:
I'm trying to disable all logging from Solr, or at least re-route it to
a file.
I
On 3/2/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
How do you all feel about returning an error when you add a document
with unknown fields?
+1
dynamicField definitions can be used if desired (including "*" to
match every undefined field).
-Yonik
On Mar 3, 2007, at 12:56 PM, Brian Whitman wrote:
I'm trying to disable all logging from Solr, or at least re-route
it to a file.
Hi Brian, all you have to do is create a logging.properties file and
call this before starting up solr:
System.setProperty("java.util.logging.config.file",
I was bit by this, tool. It made getting started a lot harder.
I think I had something outside of an instead of inside.
More recently, I got a query time exception from a mis-formatted
field.
Right now, Solr accesses the DOM as needed (at runtime) to fetch
information. There isn't much up-front
I'm trying to disable all logging from Solr, or at least re-route it
to a file.
I was finally able to disable Jetty logging through a custom
org.mortbay.log.Logger class, but I am still seeing the Solr logs,
which seem to come from java.util.logging.Logger.
Is there a thing I can do in so
On 3/3/07, Dimitar Ouzounov <[EMAIL PROTECTED]> wrote:
But what hardware problem could it be? Tomorrow I'll make sure that the
memory is fine, but nothing
else comes to my mind.
Memory, motherboard, etc.
Try http://www.memtest86.com/ to test this.
It may be OS-related - probably a buggy versi
But what hardware problem could it be? Tomorrow I'll make sure that the
memory is fine, but nothing
else comes to my mind. It may be OS-related - probably a buggy version of
some library. But which library?
On 3/3/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
On 3/3/07, Dimitar Ouzounov <[
On 3/3/07, Dimitar Ouzounov <[EMAIL PROTECTED]> wrote:
...I tried using JDK 1.5.0_05, 1.5.0_10, 1.5.0_11, and 1.6.0. I used the Java
-server mode, tried increasing the heap size, but the JVM
still crashes...
Makes me wonder if it's not your new machine that's at fault (hardware
or OS problem m
Hi everybody.
I've been using Solr for more than two months and I was really happy with it
since yesterday. I moved my application
to a faster machine and everything went wrong. I have a PHP script, which
uses libcurl to post records to Solr. It's
sending 100 records at a time. After all 2500 reco
Bertrand Delacretaz wrote:
On 3/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
...The rationale with the solrconfig stuff is that a broken config
should
behave as best it can. This is great if you are running a real site
with people actively using it - it is a pain in the ass if you are
getti
On 3/3/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
...The rationale with the solrconfig stuff is that a broken config should
behave as best it can. This is great if you are running a real site
with people actively using it - it is a pain in the ass if you are
getting started and don't notice e
28 matches
Mail list logo
