Right I read those comments in the config, and it all sounds reasonable
- presumably a new Searcher is opened when (or shortly after) we commit,
from whatever source. That was my operating assumption, and the reason
I was so confused when I saw different result in two different clients.
I don't want to pursue this probable user error beyond eliminating the
obvious for the moment. I'll post back if I get more info. Thanks
again everyone.
-Mike
On 5/2/2011 8:09 PM, Chris Hostetter wrote:
: I saw a comment recently (from Lance) that there is (annoying) HTTP caching
: enabled by default in solrconfig.xml. Does this sound like something that
: would be caused by that cache? If so, I'd probably want to disable it. Does
the HTTP caching that tends to bite people in the ass is actually your
*browser* caching the responses from solr based on the headers solr sets
in the response....
http://wiki.apache.org/solr/SolrConfigXml#HTTP_Caching
In most browsers a "Shift-Reload" tells it to ignore it's cache a force a
new request.
: that affect performance of queries run via SolrJ? Also: why isn't that cache
: flushed by a commit? Seems weird...
if you use the example configs that came with Solr 1.4.1, then solr would
generate Last-Modified and ETag headers that *would* tell your browser
that the results had chaged after commit.
If you use the example configs that came with SOlr 3.1, then solr sets the
headers in such a way that the browser shouldn't cache at all.
-Hoss
