I just tested out what you've mentioned and see the same behavior. I think it calls for a JIRA and a fix. distrib=false shouldn't consult zk in my opinion, else it makes no sense to have that param. I'm not sure but it might just be regression.
Can you create a JIRA? I'll take it up soon if no one else does. On Fri, May 15, 2015 at 10:45 PM, Shai Erera <ser...@gmail.com> wrote: > Yes. Here's what I do: > > Start two embedded Solr nodes (i.e. like using MiniSolrCloudCluster). They > were started on ports 63175 and 63201. > > Create a collection with one shard and replica. > /solr/admin/collections?action=clusterstatus shows it was created on > 127.0.0.1:63201_solr. > > Index a document: curl -i -X POST > http://127.0.0.1:63175/solr/mycollection/update/json?commit=true -d > '[{"id":"doc1"}]' > > Verify 63175 contains no cores: > http://127.0.0.1:63175/solr/admin/cores?action=status > Verify 63201 contains one core: > http://127.0.0.1:63201/solr/admin/cores?action=status -- returns an index > w/ numDocs=maxDoc=1. > > All of these return the document though: > > http://127.0.0.1:63175/solr/mycollection/select?q=* > http://127.0.0.1:63175/solr/mycollection/select?q=*&distrib=false > http://127.0.0.1:63175/solr/mycollection_shard1_replica1/select?q=* > > http://127.0.0.1:63175/solr/mycollection_shard1_replica1/select?q=*&distrib=false > > This returns "Can not find: /solr/core_node1/select" on both nodes (which > is expected since there's no such core on any of the nods): > http://127.0.0.1:63175/solr/core_node1/select?q=* > > Shai > > On Sat, May 16, 2015 at 8:08 AM, Anshum Gupta <ans...@anshumgupta.net> > wrote: > > > Did you also try querying /core.name/select with distrib=false ? > > > > On Fri, May 15, 2015 at 9:22 PM, Shai Erera <ser...@gmail.com> wrote: > > > > > Hi > > > > > > Is there a REST API in Solr that allows me to query a certain > > Replica/core? > > > I am writing some custom replica-recovery code and I'd like to verify > > that > > > it works well. > > > > > > I wanted to use the /collection/select API, passing > > > shards=host.under.test:ip/solr/collection, but that also works even if > > > 'host.under.test' does not hold any local replicas. This makes sense > > from a > > > distributed search perspective, but doesn't help me. Also, passing > > > distrib=false, which I found by searching the web, didn't help and > seems > > to > > > be ignored, or at least there's still a fallback that makes > > > 'host.under.test' access the other nodes in the cluster to fulfill the > > > request. > > > > > > Next I looked at /admin/cores?action=STATUS API. This looks better as > it > > > allows me to list the cores on 'host.under.test' and I can get > index-wide > > > statistics such as numDocs and maxDoc. This is better cause in my > tests I > > > know how many documents I should expect. > > > > > > But I was wondering if > > > > > > (1) Is Core admin API the proper way to achieve what I want, or is > there > > a > > > better way? > > > (2) Is there core-specific API for select/get, like there is for > > > /collection. I tried /core.name/select, but again, I received results > > even > > > when querying the node w/ no local replicas. > > > > > > Shai > > > > > > > > > > > -- > > Anshum Gupta > > > -- Anshum Gupta
