On 1/27/2018 6:53 AM, SOLR4189 wrote:
1. You are right, due to memory and garbage collection issues I set each shard to different VM. So in my VM I has 50 GB RAM (10 GB for JVM and 40 GB for index) and it works good for my using case. Maybe I don't understand solr terms, but if you say to set one VM for 20 shards what does it mean? 20 nodes or 20 JVMs or 20 solr instances on the same virtual server? Can you explain what did you mean?
Generally you're going to have one Solr instance per machine, whether that machine is physical or virtual. One Solr instance can handle many indexes (cores). Running multiple Solr instances per machine involves a fair amount of overhead, mostly memory, and isn't recommended except for some very specific circumstances with *huge* Java heaps.
I can't actually speak for Sameer here, but I think they likely meant that you would have two Solr instances, each with 20 cores. They would be in two virtual machines, and ideally, those virtual machines would be each hosted by a completely separate physical host.
2. I speak about like issues: "facet perfomance regression" or "using ltr with grouping" or "using timeAllowed with grouping". Something that will stop me to use replicas feature. Sometimes I don't understand solr issues, for example, if bug is unresolved and affects version 4.10 and fix version none, what does it mean? This bug can happen in solr-6.5.1 also?
It's almost impossible to say whether 6.5.1 would be affected using only the version fields in Jira. Usually if the fix-version is empty, the issue hasn't been fixed ... but there are sometimes problems which exist in an older version, but have been fixed by a later change. That later change might be completely unrelated to the issue, but the developer just happened to see something in the code they examined that they didn't like.
What's the issue state? If it is Closed or Resolved (and the resolution says Fixed), then the fix-version SHOULD indicate which versions the fix is in or will be in. If it's not resolved/closed, then it's most likely not fixed at all, no matter what the fix-version field states. As far as I am aware, the only state transition that can be automatically done by Jira itself is Fixed->Closed, and even that automatic transition only takes place with user action -- as part of the release process for a new version of Lucene/Solr. The general rule (which might not always happen) is that if the issue is not fixed, fix-version should be empty.
Thanks, Shawn
