lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lee, Peter" <Peter....@proquest.com>
Subject RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1
Date Wed, 15 May 2013 21:14:29 GMT
Shawn,

Sorry I did not acknowledge the additional information you provided. 

I'd have to go back and re-examine all of the 3.5  settings again as we had to much with them
somewhat to get 4.2.1 to work. Q.alt was a bit trickey, I have to review our notes on that.

I solved the problem of the missing "q" parameter exactly as you suggested: by putting q=*:*
in the defaults portion of the request handler and we started getting our results again.

-----Original Message-----
From: Lee, Peter 
Sent: Tuesday, May 14, 2013 5:19 PM
To: solr-user@lucene.apache.org
Subject: RE: Looking to see if solrj 3.5 could be used with solr server 4.2.1

Sounds like I may not have all of the conditions correctly identified. Or rather, things in
our environment that I did not think were a factor may very well be.  For one thing, I see
I neglected to mention that this was a grouping (field collapsing) query. Let me give you
more complete information about the query...it will probably help.

I can tell you that after the request handler processing was complete, these were the only
parameters that were set in the query:

q - was not set
defType = edismax
df = <was set>
echoParams = explicit
rows = 100
start = 0
fq = <was set>
group = true
group.field  = <was set>
group.limit = 1
group.offset = 0
group.cache.percent = 100
fl = <set to various fields>
shards = <set to the list of shards>

All of the above parameters were set in the "defaults" portion of the request handler definition.
Nothing else was being set in any other part of the request handler definition. Also, the
raw query coming into the system contained ONLY the request handler specification...nothing
else (all other parameters were being added by the request handler).

Perhaps with this more complete information you might be able to recreate the issue. I would
try right now but I'm under the gun for a release so I'll pass this information off to you.
If you are still unsuccessful when we get this release out I'll see if I can tinker with it
more and see what the determining factors are in the behavior we were seeing.

Of course, other settings in the config files might be impacting this behavior...but one thing
at a time I suppose.

Thanks.

Peter S. Lee

-----Original Message-----
From: Shawn Heisey [mailto:solr@elyograg.org] 
Sent: Tuesday, May 14, 2013 4:54 PM
To: solr-user@lucene.apache.org
Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1

On 5/14/2013 1:44 PM, Lee, Peter wrote:
> The cause:
>   We had an unintentional case that occurred through one request handler such that after
the query was processed through the RH and the parameters were set, there were fq variables
set but no actual "q" (query) param.
>   - Under solr 3.5, solr seems to assume you MEANT to specify q=*:*
>  - Under solr 4.2.1, solr makes no such assumption (or so it seems). It appears as if
solr has decided that since we didn't bother to include a 'q' parameter, it isn't going to
bother to search for anything (yes, I'm anthropomorphizing...it was a late night). I tried
the same query with the same request handler back and forth between the two versions of solr
server and one returned my data set and the other gave me zero hits.

I can't seem to duplicate this behavior.  If I send a request to 3.5.0 with no q parameter
and an fq parameter, I get an exception:

http://server35:port/solr/ncmain/select?rows=0&fq=field:value

--
HTTP ERROR 500

Problem accessing /solr/ncmain/select. Reason:

    null

java.lang.NullPointerException
--

If I send the same request to a 4.2.1 server, I get a response, but numFound is zero:

http://server421:port/solr/ncmain/select?rows=0&fq=field:value

I *had* thought that if you include q.alt=*:* in your request handler definition it would
fall back to that, but that appears to only be the case if you are using the dismax/edismax
query parser, not the standard parser.  I have a different request handler for edismax which
includes q.alt in the definition, and the queries above work fine when using that handler
instead of /select.

One thing that would most likely work is to include the q parameter in the defaults section
of your request handler.  If you don't include it in your query, it would pick up the default,
but if you did include it, the default would be ignored.

Thanks,
Shawn





Mime
View raw message