Re: updates not reflected in solr admin
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
Re: updates not reflected in solr admin
No - this is all running against an external tomcat-based solr. I'm back to being mystified now. Maybe I'll see if I can isolate this a bit more. I'll post back if I do, although I'm beginning to wonder if we should just move to 3.1 and not worry about it. -Mike On 5/2/2011 8:39 PM, Jonathan Rochkind wrote: On 5/2/2011 8:02 PM, Chris Hostetter wrote: Huh? No ... that's not true at all. A commit using SolrJ is no differnet then a commit via HTTP ... especially since that's all SOlrJ is doing when you ask it to commit. Unless you're using the 'embedded' solr server? Wonder if the OP is. Jonathan
Re: updates not reflected in solr admin
On 5/2/2011 8:02 PM, Chris Hostetter wrote: Huh? No ... that's not true at all. A commit using SolrJ is no differnet then a commit via HTTP ... especially since that's all SOlrJ is doing when you ask it to commit. Unless you're using the 'embedded' solr server? Wonder if the OP is. Jonathan
Re: updates not reflected in solr admin
: 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
Re: updates not reflected in solr admin
: > Thanks - we are issuing a commit via SolrJ; I think that's the same : > thing, right? Or are you saying really we need to do a separate commit : > (via HTTP) to update the admin console's view? ... : > Yes separate commit is needed. Huh? No ... that's not true at all. A commit using SolrJ is no differnet then a commit via HTTP ... especially since that's all SOlrJ is doing when you ask it to commit. -Hoss
Re: updates not reflected in solr admin
Ah - I didn't expect that. Thank you! On 05/02/2011 12:07 PM, Ahmet Arslan wrote: Thanks - we are issuing a commit via SolrJ; I think that's the same thing, right? Or are you saying really we need to do a separate commit (via HTTP) to update the admin console's view? Yes separate commit is needed.
Re: updates not reflected in solr admin
Thanks - we are issuing a commit via SolrJ; I think that's the same thing, right? Or are you saying really we need to do a separate commit (via HTTP) to update the admin console's view? Yes separate commit is needed.
Re: updates not reflected in solr admin
Thanks - we are issuing a commit via SolrJ; I think that's the same thing, right? Or are you saying really we need to do a separate commit (via HTTP) to update the admin console's view? -Mike On 05/02/2011 11:49 AM, Ahmet Arslan wrote: This is in 1.4 - we push updates via SolrJ; our application sees the updates, but when we use the solr admin screens to run test queries, or use Luke to view the schema and field values, it sees the database in its state prior to the commit. I think eventually this seems to propagate, but I'm not clear how often since we generally restart the (tomcat) server in order to get the new commit to be visible. You need to issue a commit from HTTP interface to see the changes made by embedded solr server. solr/update?commit=true
Re: updates not reflected in solr admin
This is in 1.4 - we push updates via SolrJ; our application sees the updates, but when we use the solr admin screens to run test queries, or use Luke to view the schema and field values, it sees the database in its state prior to the commit. I think eventually this seems to propagate, but I'm not clear how often since we generally restart the (tomcat) server in order to get the new commit to be visible. You need to issue a commit from HTTP interface to see the changes made by embedded solr server. solr/update?commit=true
updates not reflected in solr admin
This is in 1.4 - we push updates via SolrJ; our application sees the updates, but when we use the solr admin screens to run test queries, or use Luke to view the schema and field values, it sees the database in its state prior to the commit. I think eventually this seems to propagate, but I'm not clear how often since we generally restart the (tomcat) server in order to get the new commit to be visible. 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 that affect performance of queries run via SolrJ? Also: why isn't that cache flushed by a commit? Seems weird... -- Michael Sokolov Engineering Director www.ifactory.com
