If you're talking about the core admin API, it is entirely local basis,
that code is completely unaware of anything having to do with collections.
So it works but the ability to forte one core then have questions is
pretty high
Best,
Erick
On Tue, Mar 15, 2016 at 12:05 PM, Nick Vasilyev
wro
I had another collection I was running into this issue with, so I decided
to play around with it. This one had active indexing going on, so I was
able to confirm how the counts get updated. Basically, it looks like
clicking the reload button will only send a commit to that one core, it
will not be
Yea, the code sends actual commits, but I hate typing so usually just click
the reload button unless it's production.
On Mar 15, 2016 12:22 PM, "Erick Erickson" wrote:
> bq: Not sure what the issue was, in previous versions of Solr, clicking
> reload
> would send a commit to all replicas, right
>
bq: Not sure what the issue was, in previous versions of Solr, clicking reload
would send a commit to all replicas, right
Reloading doesn't really have anything to do with commits. Reload
would certainly
cause a new searcher to be opened and thus would pick up any changes
that hat been hard-commit
I reloaded the collection and ran distrib=false query for several shards on
both replicas. The counts matched exactly.
I then reloaded the second replica (through the UI) and now it seems like
it is working fine, I am getting consistent matches.
Not sure what the issue was, in previous versions o
This is very strange. What are the results you get when
you compare replicas in th e_same_ shard? It doesn't really
mean anything when you say
"shard1 has X docs, shard2 has Y docs". The only way
you should be getting different results from
the match all docs query is if different replicas within t
