[jira] [Commented] (SOLR-10656) Collection re-registering after deletion
[ https://issues.apache.org/jira/browse/SOLR-10656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005007#comment-16005007 ] Victor Igumnov commented on SOLR-10656: --- Looks like Solr 6.5.x defaults to true for the legacyCloud option if not defined. Thank you for the hint on tracking it down. https://github.com/apache/lucene-solr/blob/branch_6_5/solr/core/src/java/org/apache/solr/cloud/Overseer.java#L760 This issue can be closed, just unexpected behavior. > Collection re-registering after deletion > > > Key: SOLR-10656 > URL: https://issues.apache.org/jira/browse/SOLR-10656 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 6.5.1 > Environment: Linux / Ubuntu >Reporter: Victor Igumnov > Labels: bug > > Taking a single node down in a multi-node solr cloud cluster and then issuing > a delete collection command will succeed with a HTTP 200. The collection will > be removed from ZK and the data files removed from the active nodes. Once the > downed node is brought back into the cluster the deleted collection > re-registers it self with zookeeper and is actively queryable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10656) Collection re-registering after deletion
Victor Igumnov created SOLR-10656: - Summary: Collection re-registering after deletion Key: SOLR-10656 URL: https://issues.apache.org/jira/browse/SOLR-10656 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 6.5.1 Environment: Linux / Ubuntu Reporter: Victor Igumnov Taking a single node down in a multi-node solr cloud cluster and then issuing a delete collection command will succeed with a HTTP 200. The collection will be removed from ZK and the data files removed from the active nodes. Once the downed node is brought back into the cluster the deleted collection re-registers it self with zookeeper and is actively queryable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10194) Unable to use the UninvertedField implementation with legacy facets
[ https://issues.apache.org/jira/browse/SOLR-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882845#comment-15882845 ] Victor Igumnov commented on SOLR-10194: --- I actually found the core cause of the performance issue, it was due to too many segments on disk. Minimizing the amount of segments on disk brought the performance on par with solr 4.10. However, this is still a legitimate bug where the use of the UninvertedField implementation is blocked from use without the activation of facet.distrib.mco=true. I haven't tried docValues with the minimized amount of segments yet, but our index leans toward the static side of things so the UninvertedField implementation at query time is the ideal use case. > Unable to use the UninvertedField implementation with legacy facets > --- > > Key: SOLR-10194 > URL: https://issues.apache.org/jira/browse/SOLR-10194 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 6.2, 6.3, 6.4.1 > Environment: Linux >Reporter: Victor Igumnov >Priority: Minor > Labels: easyfix > > FacetComponent's method "modifyRequestForFieldFacets" modifies the > distributed facet request and sets the mincount count to zero which then the > SimpleFacets implementation is unable to get into the UIF code block when > facet.method=uif is applied. The workaround which I found is to use > facet.distrib.mco=true which sets the mincount to one instead of zero. > Working: > http://somehost:9100/solr/collection/select?facet.method=uif=attribute=*:*=true=true=true > > None-Working: > http://somehost:9100/solr/collection/select?facet.method=uif=attribute=*:*=true=true=false > Semi-working when it isn't a distributed call: > http://somehost:9100/solr/collection/select?facet.method=uif=attribute=*:*=true=true=false=false > Just make sure to run it on a multi-shard setup. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10194) Unable to use the UninvertedField implementation with legacy facets
Victor Igumnov created SOLR-10194: - Summary: Unable to use the UninvertedField implementation with legacy facets Key: SOLR-10194 URL: https://issues.apache.org/jira/browse/SOLR-10194 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 6.4.1, 6.3, 6.2 Environment: Linux Reporter: Victor Igumnov Priority: Minor FacetComponent's method "modifyRequestForFieldFacets" modifies the distributed facet request and sets the mincount count to zero which then the SimpleFacets implementation is unable to get into the UIF code block when facet.method=uif is applied. The workaround which I found is to use facet.distrib.mco=true which sets the mincount to one instead of zero. Working: http://somehost:9100/solr/collection/select?facet.method=uif=attribute=*:*=true=true=true None-Working: http://somehost:9100/solr/collection/select?facet.method=uif=attribute=*:*=true=true=false Semi-working when it isn't a distributed call: http://somehost:9100/solr/collection/select?facet.method=uif=attribute=*:*=true=true=false=false Just make sure to run it on a multi-shard setup. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
