hi,
i've sorted it all out. basically a few replicas had failed and the
counts on the replicas were less than the leader., i basically killed the
index on those replicas and let them recover.
Thanks for the help.
msj
On Mon, Sep 9, 2013 at 11:08 AM, Shawn Heisey <s...@elyograg.org> wrote:
> On 9/7/2013 2:25 PM, mike st. john wrote:
> > yes the collections api ignored it, what i ended up doing, was just
> > building out some fairness in regards to creating the cores and calling
> > coreadmin to create the cores, seemed to work ok. Only issue i'm having
> > now, and i'm still investigating is subsequent queries are returning
> > different counts.
>
> Every time I have seen distributed queries return different counts on
> different runs, it is because documents with the same value in the
> UniqueKey field exist in more than one shard. If you are letting
> SolrCloud route your documents automatically, this shouldn't happen ...
> but if you are using distrib=false or a router that doesn't do it
> automatically, then it could.
>
> The Collections API doesn't do the dataDir parameter. I suspect this is
> because you could pass an absolute path in, which would break things
> because every core would be trying to use the same dataDir. If you want
> a directory other than ${instanceDir}/data for dataDir, then you will
> need to create each core individually rather than use the Collections API.
>
> Java does have the capability to determine whether a path is relative or
> absolute, but it is safer to just ignore that parameter, especially
> given the fact that a single cloud is usually on many servers, and
> there's no reason those servers can't be running wildly different
> operating systems. Half your cloud could be on a Linux/UNIX OS and half
> of it could be on Windows.
>
> I personally find it better to let the Collections API do its thing and
> use the default.
>
> Thanks,
> Shawn
>
>
