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
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, Jonath
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.
Jonatha
: 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 actu
: > 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 usin
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
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.
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 applica
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
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
10 matches
Mail list logo