On 10/14/2018 10:39 PM, Shalin Shekhar Mangar wrote:
The responses are collected by node so subsequent responses from the same
node overwrite previous responses. Definitely a bug. Please open an issue.
Done.
https://issues.apache.org/jira/browse/SOLR-12867
Thanks,
Shawn
The responses are collected by node so subsequent responses from the same
node overwrite previous responses. Definitely a bug. Please open an issue.
On Mon, Oct 15, 2018 at 6:24 AM Shawn Heisey wrote:
> On 10/14/2018 6:25 PM, dami...@gmail.com wrote:
> > I had an issue with async backup on solr
On 10/14/2018 9:31 PM, Sourav Moitra wrote:
My question does running separate zookeeper ensemble in the same boxes
provides any advantage over using the solr embedded zookeeper ?
The major disadvantage to having ZK embedded in Solr is this: If you
stop or restart the Solr process, part of
Hello,
As per the documentation it is preferable to use external zookeeper
service. I am provisioning 3 Solr servers with each having Solr 7.5 in
cloud mode and seperate zookeeper daemon process running. The
zookeepers of each boxes are configured to form ensemble among them.
My question does
On 10/14/2018 6:25 PM, dami...@gmail.com wrote:
I had an issue with async backup on solr 6.5.1 reporting that the backup
was complete when clearly it was not. I was using 12 shards across 6 nodes.
I only noticed this issue when one shard was much larger than the others.
There were no answers
Hi Shawn,
I had an issue with async backup on solr 6.5.1 reporting that the backup
was complete when clearly it was not. I was using 12 shards across 6 nodes.
I only noticed this issue when one shard was much larger than the others.
There were no answers here
I had a quick question regarding using Solr for doing fast geospatial
calculations against multiple locations. For example we have a product that
takes 2 to 10 companies at a time (i.e. McDonalds 14,000 Subway 20,000, Duncan
Donuts 5000), and identifies and maps any store overlap based on a
On 10/14/2018 6:32 AM, yasoobhaider wrote:
Memory Analyzer output:
One instance of "org.apache.solr.uninverting.FieldCacheImpl" loaded by
"org.eclipse.jetty.webapp.WebAppClassLoader @ 0x7f60f7b38658" occupies
61,234,712,560 (91.86%) bytes. The memory is accumulated in one instance of
After none of the JVM configuration options helped witH GC, as Erick
suggested I took a heap dump of one of the misbehaving slaves and analysis
shows that fieldcache is using a large amount of the the total heap.
Memory Analyzer output:
One instance of
