Logging in the example solr+jetty setup
Hi There,
I'm new to solr, and so far I've been impressed. One thing I'm curious
about, as a newbie, is the source of some of the log messages that
show up in the example solr+jetty setup, found in the 1.2
distribution's example directory.
I'm seeing two kinds of log messages. First there are ones of this sort:
Sep 23, 2007 1:20:06 AM org.apache.solr.handler.XmlUpdateRequestHandler update
Sep 23, 2007 1:20:06 AM org.apache.solr.core.SolrCore execute
Sep 23, 2007 1:20:06 AM org.apache.solr.update.DirectUpdateHandler2 commit
which seem to be debugging info about which methods in the solr code
are being invoked. Then there are ones of this sort
INFO: added id={3007WFP} in 77ms
INFO: /update 0 82
INFO: start commit(optimize=false,waitFlush=false,waitSearcher=true)
which provide a more user-oriented, action-centric (vs code-centric)
perspective.
The latter messages, I see, are generated in the solr code, in calls
to log.info(), log.severe(), etc.. But where are the code-oriented,
method invocation messages being generated? Perhaps the solr code is
generating these as well, though I haven't found code for it yet. Is
this perhaps something that jetty is doing? Does the example jetty
setup somehow ask the java VM to automatically log certain method
calls?
Thanks,
Chris
real time search
i wanna do it. Maybe someone did it, if so, give me some tips. thks -- regards jl
Re: Logging in the example solr+jetty setup
Okay, I figured it out. The method invocation messages are being
generated by the java logging api. The default logging handler in the
solr+jetty setup is java.util.logging.ConsoleHandler. That handler (or
perhaps java.util.logging.SimpleFormatter, its default formatter)
causes a what-method-am-I-in message to be printed to the console
immediately before printing the message actually passed to log.info(),
log.warning(), or whatever.
On 9/23/07, Chris Harris <[EMAIL PROTECTED]> wrote:
> Hi There,
>
> I'm new to solr, and so far I've been impressed. One thing I'm curious
> about, as a newbie, is the source of some of the log messages that
> show up in the example solr+jetty setup, found in the 1.2
> distribution's example directory.
>
> I'm seeing two kinds of log messages. First there are ones of this sort:
>
> Sep 23, 2007 1:20:06 AM org.apache.solr.handler.XmlUpdateRequestHandler update
> Sep 23, 2007 1:20:06 AM org.apache.solr.core.SolrCore execute
> Sep 23, 2007 1:20:06 AM org.apache.solr.update.DirectUpdateHandler2 commit
>
> which seem to be debugging info about which methods in the solr code
> are being invoked. Then there are ones of this sort
>
> INFO: added id={3007WFP} in 77ms
> INFO: /update 0 82
> INFO: start commit(optimize=false,waitFlush=false,waitSearcher=true)
>
> which provide a more user-oriented, action-centric (vs code-centric)
> perspective.
>
> The latter messages, I see, are generated in the solr code, in calls
> to log.info(), log.severe(), etc.. But where are the code-oriented,
> method invocation messages being generated? Perhaps the solr code is
> generating these as well, though I haven't found code for it yet. Is
> this perhaps something that jetty is doing? Does the example jetty
> setup somehow ask the java VM to automatically log certain method
> calls?
>
> Thanks,
> Chris
>
Facets and sort
Hi all, I'm currently playing with solr (a nightly build of sep. 16) to see if it can fit our needs. It's really a great piece of software and I especially appreciate the facetting features. I now have something that works really well and there's only one problem left: - I want to sort the results by title: I do it via a sort=title_t asc parameter - when I don't apply any facetting filter, it works well, my results are sorted by title. Search URL is: http://localhost:8080/solr/select?fl=%2A%2C+score&sort=titre_t+asc&facet=true&facet.mincount=1&facet.query=prix_min_i%3A%5B%2A+TO+7%5D&facet.query=prix_min_i%3A%5B8+TO+15%5D&facet.query=prix_min_i%3A%5B16+TO+30%5D&facet.query=prix_min_i%3A%5B31+TO+60%5D&facet.query=prix_min_i%3A%5B61+TO+90%5D&facet.query=prix_min_i%3A%5B91+TO+%2A%5D&f.note_i.facet.sort=false&facet.field=quartier_facet&facet.field=genres_mfacet&facet.field=note_i&version=2.2&wt=json&q=%2B%28type_objet%3Alieu%29+%2B%28ville_facet%3ALYO%29+%2B%28theme_facet%3ARES%29+&start=0&rows=20 - the problem is that as soon as I apply a facetting filter via qf=facet:value, I can't get my results sorted. Search URL: http://localhost:8080/solr/select?fl=%2A%2C+score&sort=titre_t+asc&facet=true&facet.mincount=1&facet.query=prix_min_i%3A%5B%2A+TO+7%5D&facet.query=prix_min_i%3A%5B8+TO+15%5D&facet.query=prix_min_i%3A%5B16+TO+30%5D&facet.query=prix_min_i%3A%5B31+TO+60%5D&facet.query=prix_min_i%3A%5B61+TO+90%5D&facet.query=prix_min_i%3A%5B91+TO+%2A%5D&f.note_i.facet.sort=false&facet.field=quartier_facet&facet.field=genres_mfacet&facet.field=note_i&fq=quartier_facet%3ALY02E&version=2.2&wt=json&q=%2B%28type_objet%3Alieu%29+%2B%28ville_facet%3ALYO%29+%2B%28theme_facet%3ARES%29+&start=0&rows=20 Is there anything special to do to have sorted results when using facetting? If the problem is not obvious, I can provide more information if needed. Thanks in advance. -- Guillaume
Re: Continue posting after an error
: Sometimes there's a field that shouldn't be multiValued, but the data comes in : with multiple fields of the same name in a single document. : : Is there any way to continue processing other documents in a file even if one : document errors out? It seems like whenever we hit one of these cases, it : stops processing the file completely. I believe you are correct, the UpdateRequestHandler aborts as soon as bad doc is found. It might be possible to make it skip bad docs and continue processing, but what mechanism could it use to report which doc had failed? not all schemas have uniqueKey fields, and even if they do - the uniqueKey field may have been the problem. This is one of the reasons why i personally recommend only sending one doc at a time -- if you use persistent HTTP connections, there really shouldn't be much performance differnece (and if there is, we can probably optimize that) -Hoss
Re: logging bad stuff separately in resin
: Is there a way to filter the log that goes into resin by "bad/fatal" stuff : separate from the usual request logging? I would like to put the solr errors : somewhere else so it's more maintainable. Resin actually has one of the best logging configuration mechanisms i've seen, the docs from caucho should be pretty self explanaitory... http://www.caucho.com/resin-3.0/config/log.xtp#log ...you can easily modify your resin.conf it up so that SEVERE or WARNING logs from sol go some place special, while other messages from solr (or other apps) so someplace else. the one option that *still* seems to be undocumented in the official docs is "use-parent-handlers" ... but it does seem to be mentioned in their wiki. in my experience you frequently want it to be "false"... http://wiki.caucho.com/Log -Hoss
Re: Facets and sort
: - I want to sort the results by title: I do it via a sort=title_t asc parameter : - when I don't apply any facetting filter, it works well, my results : are sorted by title. Search URL is: ... : - the problem is that as soon as I apply a facetting filter via : qf=facet:value, I can't get my results sorted. Search URL: a couple of things... 1) "qf" is not a faceting or filtering option ... it's a dismax specific option and you don't seem to be using dismax. ... i think you ment "fq" (which is what actually seems to be different in the two URLs) 2) you said you want to sort on "title_t asc" ... but in both URLs you are sorting on "titre_t asc" ... i'm not certain which one is the typo, but i'm guessing it's the URLs and if you look closely at all the pages of results i'm guessing the first query isn't really sorting correctly either. -Hoss
Re: jira 243
:was wondering if there are any plans of merging this patch into svn. Hey John: I'm going to leave this message in my inbox as a reminder to look at the latest patch when i get a chance ... but at this point i'm having a hard enough time keeping up with geniune bugs, and feature patche people have voted on in Jira (or that have a lot of discussion) -Hoss
Re: jira 243
Thanks Chris. -John On 9/23/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > > :was wondering if there are any plans of merging this patch into svn. > > Hey John: I'm going to leave this message in my inbox as a reminder to > look at the latest patch when i get a chance ... but at this point i'm > having a hard enough time keeping up with geniune bugs, and feature > patche people have voted on in Jira (or that have a lot of discussion) > > -Hoss > >
