Thanks Jim. We've been using the composite id approach where we put group value as the leading portion of the id (i.e. groupValue!documentid), so I was expecting all of the documents for a given group to be in the same shard, but at least this gives me something to look into. I'm still suspicious of something changing between 4.6.1 and 4.8.1, because we've had the grouping implemented this way for a while, and only on the exact day we upgraded did someone bring this problem forward. I will keep investigating, thanks.
On Fri, Aug 22, 2014 at 9:18 AM, jim ferenczi <jim.feren...@gmail.com> wrote: > Hi Bryan, > This is a known limitations of the grouping. > https://wiki.apache.org/solr/FieldCollapsing#RequestParameters > > group.ngroups: > > > *WARNING: If this parameter is set to true on a sharded environment, all > the documents that belong to the same group have to be located in the same > shard, otherwise the count will be incorrect. If you are using SolrCloud > <https://wiki.apache.org/solr/SolrCloud>, consider using "custom hashing"* > > Cheers, > Jim > > > > 2014-08-21 21:44 GMT+02:00 Bryan Bende <bbe...@gmail.com>: > > > Is there any known issue with using group.ngroups in a distributed Solr > > using version 4.8.1 ? > > > > I recently upgraded a cluster from 4.6.1 to 4.8.1, and I'm noticing > several > > queries where ngroups will be more than the actual groups returned in the > > response. For example, ngroups will say 5, but then there will be 3 > groups > > in the response. It is not happening on all queries, only some. > > >
