No, we're not doing NRT. The search clients aren't using CloudSolrServer
and they are behind an AWS load balancer, which calls the Solr ping handler
(implemented with ClusterStateAwarePingRequestHandler) to determine when
the node is active. This ping handler also responds during the index copy,
which doesn't seem right. I'll have to figure out why it does this before
the replica is really active.

Peter


On Thu, Jul 3, 2014 at 9:36 AM, Mark Miller <markrmil...@gmail.com> wrote:

> I don’t know offhand about the num docs issue - are you doing NRT?
>
> As far as being able to query the replica, I’m not sure anyone ever got to
> making that fail if you directly query a node that is not active. It
> certainly came up, but I have no memory of anyone tackling it. Of course in
> many other cases, information is being pulled from zookeeper and recovering
> nodes are ignored. If this is the issue I think it is, it should only be an
> issue when you directly query recovery node.
>
> The CloudSolrServer client works around this issue as well.
>
> --
> Mark Miller
> about.me/markrmiller
>
> On July 3, 2014 at 8:42:48 AM, Peter Keegan (peterlkee...@gmail.com)
> wrote:
>
> I bring up a new Solr node with no index and watch the index being
> replicated from the leader. The index size is 12G and the replication takes
> about 6 minutes, according to the replica log (from 'Starting recovery
> process' to 'Finished recovery process). However, shortly after the
> replication begins, while the index files are being copied, I am able to
> query the index on the replica and see q=*:* find all of the documents.
> But, from the core admin screen, numDocs = 0, and in the cloud screen the
> replica is in 'recovering' mode. How can this be?
>
> Peter
>

Reply via email to