Thanks for the hint :)
We ruled that out after having tested special characters, and if it was
an applicative bug, it wouldn't work consistently like it currently does
for the majority of queries.
The only difference we noticed was in the HTTP headers in the SOLR
response: occasionnally, the "Content-length" is present, but I've been
told it was probably not causing our bug:
=> dev:
headers = Array
(
[0] => HTTP/1.1 200 OK
[1] => Last-Modified: Fri, 29 Apr 2011 13:36:21 GMT
[2] => ETag: "MTFjZjU2MTgxNDgwMDAwMFNvbHI="
[3] => Content-Type: text/plain; charset=utf-8
[4] => Server: Jetty(6.1.3)
)
=> production:
headers = Array
(
[0] => HTTP/1.1 200 OK
[1] => Last-Modified: Fri, 06 May 2011 14:18:36 GMT
[2] => ETag: "OGI3ZWYyZDUxNDgwMDAwMFNvbHI="
[3] => Content-Type: text/plain; charset=utf-8
[4] => Content-Length: 2558
[5] => Server: Jetty(6.1.3)
)
Paul Michalet
Le 11/05/2011 17:47, Paul Libbrecht a écrit :
Could it be something in the transmission of the query?
Or is it also identical?
paul
Le 11 mai 2011 à 17:19, Paul Michalet a écrit :
Hello everyone
We have succesfully installed SOLR on 2 servers (developpement and production),
using the same configuration files and paths.
Both SOLR instances have indexed the same contents and most queries give
identical results, but there's a few exceptions where the production instance
returns 0 results (the developpement instance returns perfectly valid results
for the same query).
We checked the logs in both environments without finding anything suspicous
(the queries are rigorously identical, and the index is built in the exact same
way) and we've run out of options as to where to look for debugging these cases.
Our developpement server is Debian and the production is CentOS;
the SOLR version installed in both environments is 1.4.0.
The weird thing is that the few queries failing in the production instance
contain very common terms (without quotes) which, when queried individually,
return valid results...
Any pointers would be greatly appreciated;
thanks in advance !
Paul
