[jira] [Created] (SOLR-4716) this bug for fixed bug SOLR-4210. proxy request for remote core
Po Rui created SOLR-4716: Summary: this bug for fixed bug SOLR-4210. proxy request for remote core Key: SOLR-4716 URL: https://issues.apache.org/jira/browse/SOLR-4716 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.2 Reporter: Po Rui For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some more web server) cause the IOUtils.closeQuietly(os) wouldn't flush before close the stream in org.apache.catalina.connector.CoyoteOutputStream. this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4716) this bug for fixed bug SOLR-4210. proxy request for remote core
[ https://issues.apache.org/jira/browse/SOLR-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4716: - Description: For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some other web server too) cause the IOUtils.closeQuietly(os) wouldn't flush before close . this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1. so we should invoke flush() explicitly before close. (was: For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some more web server) cause the IOUtils.closeQuietly(os) wouldn't flush before close the stream in org.apache.catalina.connector.CoyoteOutputStream. this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1) this bug for fixed bug SOLR-4210. proxy request for remote core Key: SOLR-4716 URL: https://issues.apache.org/jira/browse/SOLR-4716 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.2 Reporter: Po Rui For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some other web server too) cause the IOUtils.closeQuietly(os) wouldn't flush before close . this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1. so we should invoke flush() explicitly before close. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4716) this bug for fixed bug SOLR-4210. proxy request for remote core
[ https://issues.apache.org/jira/browse/SOLR-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4716: - Attachment: SOLR-4716.patch this bug for fixed bug SOLR-4210. proxy request for remote core Key: SOLR-4716 URL: https://issues.apache.org/jira/browse/SOLR-4716 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.2 Reporter: Po Rui Attachments: SOLR-4716.patch For bug SOLR-4210. remoteQuery() have some issue in tomcat. it's ok in jetty but not work in tomcat(maybe some other web server too) cause the IOUtils.closeQuietly(os) wouldn't flush before close . this lead a Bogus chunk size error cause the transfer-encoding is chunked and also the Content-Length was set to non -1. so we should invoke flush() explicitly before close. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4269) Core Object doesn't be checked when remove a core from coreToOrigName in coreContainer
Po Rui created SOLR-4269: Summary: Core Object doesn't be checked when remove a core from coreToOrigName in coreContainer Key: SOLR-4269 URL: https://issues.apache.org/jira/browse/SOLR-4269 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0, 4.0-BETA, 4.0-ALPHA Reporter: Po Rui Priority: Minor Fix For: 4.0 this bug lead a No such core exists exception never happen and the exception replace by the NullPointerException from ConcurrentHashMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4269) Core Object doesn't be checked when remove a core from coreToOrigName in coreContainer
[ https://issues.apache.org/jira/browse/SOLR-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4269: - Attachment: SOLR-4269.patch Core Object doesn't be checked when remove a core from coreToOrigName in coreContainer --- Key: SOLR-4269 URL: https://issues.apache.org/jira/browse/SOLR-4269 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Priority: Minor Fix For: 4.0 Attachments: SOLR-4269.patch this bug lead a No such core exists exception never happen and the exception replace by the NullPointerException from ConcurrentHashMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3978) CoreAdmin - configName definition
[ https://issues.apache.org/jira/browse/SOLR-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13544597#comment-13544597 ] Po Rui commented on SOLR-3978: -- miss -Dbootstrap_confdir= CoreAdmin - configName definition - Key: SOLR-3978 URL: https://issues.apache.org/jira/browse/SOLR-3978 Project: Solr Issue Type: Bug Components: multicore Environment: * Solr 3.6.1 * Jetty 8.1.5.v20120716 Reporter: Gianluca Varisco Priority: Minor Hello, I'm trying to define a bunch of cores as follows: core name=venus instanceDir=/opt/solr-3.6.1/staging/venus/ dataDir=/opt/solr-3.6.1/staging/venus/data/ configName=/shop/www/htdocs/venus/shop.staging/solr/app/conf/solrconfig.xml schemaName=/shop/www/htdocs/venus/shop.staging/solr/app/conf/schema.xml / Is it possible to point configName and schemaName to a different path? It works if conf/solrconfig.xml is added in /opt/solr-3.6.1/staging/venus/ Am I missing something? Trace output is attached. SEVERE: java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or '/opt/solr-3.6.1/staging/venus/conf/', cwd=/opt/jetty/staging at org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:273) at org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:239) at org.apache.solr.core.Config.init(Config.java:141) at org.apache.solr.core.SolrConfig.init(SolrConfig.java:138) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:452) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:332) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:216) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:161) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:96) at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:114) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:258) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1233) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:701) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:475) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:36) at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:183) at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:491) at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:138) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:142) at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:53) at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:604) at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:535) at org.eclipse.jetty.util.Scanner.scan(Scanner.java:398) at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:332) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:118) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:552) at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:227) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:75) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:53) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:91) at org.eclipse.jetty.server.Server.doStart(Server.java:272) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1260) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1183) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] [Comment Edited] (SOLR-3978) CoreAdmin - configName definition
[ https://issues.apache.org/jira/browse/SOLR-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13544597#comment-13544597 ] Po Rui edited comment on SOLR-3978 at 1/5/13 6:11 AM: -- miss -Dbootstrap_confdir= , specified your conf dir was (Author: brui): miss -Dbootstrap_confdir= CoreAdmin - configName definition - Key: SOLR-3978 URL: https://issues.apache.org/jira/browse/SOLR-3978 Project: Solr Issue Type: Bug Components: multicore Environment: * Solr 3.6.1 * Jetty 8.1.5.v20120716 Reporter: Gianluca Varisco Priority: Minor Hello, I'm trying to define a bunch of cores as follows: core name=venus instanceDir=/opt/solr-3.6.1/staging/venus/ dataDir=/opt/solr-3.6.1/staging/venus/data/ configName=/shop/www/htdocs/venus/shop.staging/solr/app/conf/solrconfig.xml schemaName=/shop/www/htdocs/venus/shop.staging/solr/app/conf/schema.xml / Is it possible to point configName and schemaName to a different path? It works if conf/solrconfig.xml is added in /opt/solr-3.6.1/staging/venus/ Am I missing something? Trace output is attached. SEVERE: java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or '/opt/solr-3.6.1/staging/venus/conf/', cwd=/opt/jetty/staging at org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:273) at org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:239) at org.apache.solr.core.Config.init(Config.java:141) at org.apache.solr.core.SolrConfig.init(SolrConfig.java:138) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:452) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:332) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:216) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:161) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:96) at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:114) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:258) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1233) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:701) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:475) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:36) at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:183) at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:491) at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:138) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:142) at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:53) at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:604) at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:535) at org.eclipse.jetty.util.Scanner.scan(Scanner.java:398) at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:332) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:118) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:552) at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:227) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:75) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:53) at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:91) at org.eclipse.jetty.server.Server.doStart(Server.java:272) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:59) at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1260) at java.security.AccessController.doPrivileged(Native Method)
[jira] [Created] (SOLR-4210) if couldn't find the collection locally when searching, we should look on other nodes
Po Rui created SOLR-4210: Summary: if couldn't find the collection locally when searching, we should look on other nodes Key: SOLR-4210 URL: https://issues.apache.org/jira/browse/SOLR-4210 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0, 4.0-BETA Reporter: Po Rui Priority: Critical Fix For: 4.0, 4.0-BETA It only check the local collection or core when searching, doesn't look on other nodes. e.g. a cluster have 4 nodes. 1th 2th 3th contribute to collection1. 2th 3th 4th contribute to collection2. now send query to 4th to searching collection1 will failed. It is an imperfect feature for searching. it is a TODO part in SolrDispatchFilter-line 220. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4210) if couldn't find the collection locally when searching, we should look on other nodes. one of TODOs part in SolrDispatchFilter
[ https://issues.apache.org/jira/browse/SOLR-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4210: - Summary: if couldn't find the collection locally when searching, we should look on other nodes. one of TODOs part in SolrDispatchFilter (was: if couldn't find the collection locally when searching, we should look on other nodes) if couldn't find the collection locally when searching, we should look on other nodes. one of TODOs part in SolrDispatchFilter --- Key: SOLR-4210 URL: https://issues.apache.org/jira/browse/SOLR-4210 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-BETA, 4.0 It only check the local collection or core when searching, doesn't look on other nodes. e.g. a cluster have 4 nodes. 1th 2th 3th contribute to collection1. 2th 3th 4th contribute to collection2. now send query to 4th to searching collection1 will failed. It is an imperfect feature for searching. it is a TODO part in SolrDispatchFilter-line 220. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4210) if couldn't find the collection locally when searching, we should look on other nodes. one of TODOs part in SolrDispatchFilter
[ https://issues.apache.org/jira/browse/SOLR-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4210: - Attachment: SOLR-4210.patch if couldn't find the collection locally when searching, we should look on other nodes. one of TODOs part in SolrDispatchFilter --- Key: SOLR-4210 URL: https://issues.apache.org/jira/browse/SOLR-4210 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-BETA, 4.0 Attachments: SOLR-4210.patch It only check the local collection or core when searching, doesn't look on other nodes. e.g. a cluster have 4 nodes. 1th 2th 3th contribute to collection1. 2th 3th 4th contribute to collection2. now send query to 4th to searching collection1 will failed. It is an imperfect feature for searching. it is a TODO part in SolrDispatchFilter-line 220. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4078) Allow custom naming of nodes so that a new host:port combination can take over for a previous shard.
[ https://issues.apache.org/jira/browse/SOLR-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13511230#comment-13511230 ] Po Rui commented on SOLR-4078: -- we interest in this feature. we look foreword this feature just in case ^_^ Allow custom naming of nodes so that a new host:port combination can take over for a previous shard. Key: SOLR-4078 URL: https://issues.apache.org/jira/browse/SOLR-4078 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.1, 5.0 Attachments: SOLR-4078.patch Currently we auto assign a unique node name based on the host address and core name - we should let the user optionally override this so that a new host address + core name combo can take over the duties of a previous registered node. Especially useful for ec2 if you are not using elastic ips. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4109) can't delete inactive core in collection
Po Rui created SOLR-4109: Summary: can't delete inactive core in collection Key: SOLR-4109 URL: https://issues.apache.org/jira/browse/SOLR-4109 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0, 4.0-BETA Reporter: Po Rui Fix For: 4.0, 4.0-BETA It failed to delete a collection when any inactive core appear in the collection. the inactive core due to a lot of reasons. usually caused by recovering failed and the inactive core hard to active again only if it have chance to be a leader. but for user, he/she doesn't care the core is active or not if he/she want to delete the collection. so we should delete the inactive core too rather than stop user doing this operation. this behavior lead a collection contained inactive core almost impossible to be deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4109) can't delete inactive core in collection
[ https://issues.apache.org/jira/browse/SOLR-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4109: - Description: It failed to delete a collection when any inactive core appear in the collection. the inactive core due to a lot of reasons. usually caused by recovering failed and the inactive core hard to active again only if it have chance to be a leader. but for user, he/she doesn't care the core is active or not if he/she already decide to delete the collection. so we should delete the inactive core too rather than stop user doing this operation. this behavior lead a collection contained inactive core almost impossible to be deleted. (was: It failed to delete a collection when any inactive core appear in the collection. the inactive core due to a lot of reasons. usually caused by recovering failed and the inactive core hard to active again only if it have chance to be a leader. but for user, he/she doesn't care the core is active or not if he/she want to delete the collection. so we should delete the inactive core too rather than stop user doing this operation. this behavior lead a collection contained inactive core almost impossible to be deleted.) can't delete inactive core in collection - Key: SOLR-4109 URL: https://issues.apache.org/jira/browse/SOLR-4109 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-BETA, 4.0 It failed to delete a collection when any inactive core appear in the collection. the inactive core due to a lot of reasons. usually caused by recovering failed and the inactive core hard to active again only if it have chance to be a leader. but for user, he/she doesn't care the core is active or not if he/she already decide to delete the collection. so we should delete the inactive core too rather than stop user doing this operation. this behavior lead a collection contained inactive core almost impossible to be deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4109) can't delete inactive core in collection
[ https://issues.apache.org/jira/browse/SOLR-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4109: - Attachment: SOLR-4109.patch can't delete inactive core in collection - Key: SOLR-4109 URL: https://issues.apache.org/jira/browse/SOLR-4109 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-BETA, 4.0 Attachments: SOLR-4109.patch It failed to delete a collection when any inactive core appear in the collection. the inactive core due to a lot of reasons. usually caused by recovering failed and the inactive core hard to active again only if it have chance to be a leader. but for user, he/she doesn't care the core is active or not if he/she already decide to delete the collection. so we should delete the inactive core too rather than stop user doing this operation. this behavior lead a collection contained inactive core almost impossible to be deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3993) SolrCloud leader election on single node stucks the initialization
[ https://issues.apache.org/jira/browse/SOLR-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503023#comment-13503023 ] Po Rui commented on SOLR-3993: -- To Werner: 1)are you sure your solr is 4.0 rather than 4.0alpha or 4.0beta? generally, the situation you described lead a lot of waitForReplicasComeup log produced. if no exception it will stop 3 mins latter. those logs due to zookeeper keep those old server's info in clustersate. 2) above situation both refer to zookeeper leader reelection.all solr service can't work before this election procedure over. the solr node may die if the election time over the solr connect-zookeeper retry time. so the problem is hard to deal with since the zook leader reelection procedure is uncontrollable. SolrCloud leader election on single node stucks the initialization -- Key: SOLR-3993 URL: https://issues.apache.org/jira/browse/SOLR-3993 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: Windows 7, Tomcat 6 Reporter: Alexey Kudinov Assignee: Mark Miller Fix For: 4.1, 5.0 setup: 1 node, 4 cores, 2 shards. 15 documents indexed. problem: init stage times out. probable cause: According to the init flow, cores are initialized one by one synchronously. Actually, the main thread waits ShardLeaderElectionContext.waitForReplicasToComeUp until retry threshold, while replica cores are not yet initialized, in other words there is no chance other replicas go up in the meanwhile. stack trace: Thread [main] (Suspended) owns: HashMapK,V (id=3876) owns: StandardContext (id=3877) owns: HashMapK,V (id=3878) owns: StandardHost (id=3879) owns: StandardEngine (id=3880) owns: Service[] (id=3881) Thread.sleep(long) line: not available [native method] ShardLeaderElectionContext.waitForReplicasToComeUp(boolean, String) line: 298 ShardLeaderElectionContext.runLeaderProcess(boolean) line: 143 LeaderElector.runIamLeaderProcess(ElectionContext, boolean) line: 152 LeaderElector.checkIfIamLeader(int, ElectionContext, boolean) line: 96 LeaderElector.joinElection(ElectionContext) line: 262 ZkController.joinElection(CoreDescriptor, boolean) line: 733 ZkController.register(String, CoreDescriptor, boolean, boolean) line: 566 ZkController.register(String, CoreDescriptor) line: 532 CoreContainer.registerInZk(SolrCore) line: 709 CoreContainer.register(String, SolrCore, boolean) line: 693 CoreContainer.load(String, InputSource) line: 535 CoreContainer.load(String, File) line: 356 CoreContainer$Initializer.initialize() line: 308 SolrDispatchFilter.init(FilterConfig) line: 107 ApplicationFilterConfig.getFilter() line: 295 ApplicationFilterConfig.setFilterDef(FilterDef) line: 422 ApplicationFilterConfig.init(Context, FilterDef) line: 115 StandardContext.filterStart() line: 4072 StandardContext.start() line: 4726 StandardHost(ContainerBase).addChildInternal(Container) line: 799 StandardHost(ContainerBase).addChild(Container) line: 779 StandardHost.addChild(Container) line: 601 HostConfig.deployDescriptor(String, File, String) line: 675 HostConfig.deployDescriptors(File, String[]) line: 601 HostConfig.deployApps() line: 502 HostConfig.start() line: 1317 HostConfig.lifecycleEvent(LifecycleEvent) line: 324 LifecycleSupport.fireLifecycleEvent(String, Object) line: 142 StandardHost(ContainerBase).start() line: 1065 StandardHost.start() line: 840 StandardEngine(ContainerBase).start() line: 1057 StandardEngine.start() line: 463 StandardService.start() line: 525 StandardServer.start() line: 754 Catalina.start() line: 595 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available Method.invoke(Object, Object...) line: not available Bootstrap.start() line: 289 Bootstrap.main(String[]) line: 414 After a while, the session times out and following exception appears: Oct 25, 2012 1:16:56 PM org.apache.solr.cloud.ShardLeaderElectionContext waitForReplicasToComeUp INFO: Waiting until we see more replicas up: total=2 found=0 timeoutin=-95 Oct 25, 2012 1:16:56 PM org.apache.solr.cloud.ShardLeaderElectionContext waitForReplicasToComeUp INFO: Was waiting
[jira] [Updated] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
[ https://issues.apache.org/jira/browse/SOLR-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4098: - Attachment: SOLR-4098.patch Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly --- Key: SOLR-4098 URL: https://issues.apache.org/jira/browse/SOLR-4098 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4098.patch a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
[ https://issues.apache.org/jira/browse/SOLR-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4098: - Attachment: (was: SOLR-4098.patch) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly --- Key: SOLR-4098 URL: https://issues.apache.org/jira/browse/SOLR-4098 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4098.patch a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
[ https://issues.apache.org/jira/browse/SOLR-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4098: - Description: a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be refer by too many methods was: a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly --- Key: SOLR-4098 URL: https://issues.apache.org/jira/browse/SOLR-4098 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4098.patch a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be refer by too many methods -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
[ https://issues.apache.org/jira/browse/SOLR-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4098: - Description: a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be invoked by too many methods. I'm not sure weather this also lead some potential issue now. I'd rather believe it does. those invoker should be double check in next version was: a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be invoked by too many methods. I'm not sure weather this also lead some potential issue now. I'd rather believe it does. those should be double check in next Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly --- Key: SOLR-4098 URL: https://issues.apache.org/jira/browse/SOLR-4098 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4098.patch a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be invoked by too many methods. I'm not sure weather this also lead some potential issue now. I'd rather believe it does. those invoker should be double check in next version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
[ https://issues.apache.org/jira/browse/SOLR-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4098: - Description: a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be invoked by too many methods. I'm not sure weather this also lead some potential issue now. I'd rather believe it does. those should be double check in next was: a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be refer by too many methods Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly --- Key: SOLR-4098 URL: https://issues.apache.org/jira/browse/SOLR-4098 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4098.patch a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly I'd fixed rename/remove/reload/swap. but getCore(name) be invoked by too many methods. I'm not sure weather this also lead some potential issue now. I'd rather believe it does. those should be double check in next -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4105) SolrCloud - Restarting a Solr Node Causes Random Results
[ https://issues.apache.org/jira/browse/SOLR-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502612#comment-13502612 ] Po Rui commented on SOLR-4105: -- It cause the load balance for search. it means your search requests may not handle by instance A even you send them to A. more detail: 1 slice with 2 shards refer to A(leader) and B(replica).when you send a search request to A it assign to A or B randomly by A. so the situation in http://lucene.472066.n3.nabble.com/Weird-Behaviour-on-Solr-5x-SolrCloud-td4021219.html is normal. The problem is the restarted B doesn't recovery to the leader A. it may be a bug or cause a uncompleted feature due to the recovering base on file level and commit version SolrCloud - Restarting a Solr Node Causes Random Results - Key: SOLR-4105 URL: https://issues.apache.org/jira/browse/SOLR-4105 Project: Solr Issue Type: Bug Affects Versions: 5.0 Environment: Linux Reporter: Deniz Durmus Labels: solrcloud, solrindex For Brief description, basically restarting a Solr instance in cloud causes a weird behavior, it shows results, randomly from the instance itself and then the leader, which causes seeing 0 results and then correct amount of results. In addition to this, the restarted node wont be sync'ed with the rest of the cloud, unless you delete the data folder's contents before restarting. For more details, you can follow the thread here: You can see the details and flow of the issue here: http://lucene.472066.n3.nabble.com/Weird-Behaviour-on-Solr-5x-SolrCloud-td4021219.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3993) SolrCloud leader election on single node stucks the initialization
[ https://issues.apache.org/jira/browse/SOLR-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502629#comment-13502629 ] Po Rui commented on SOLR-3993: -- TO Werner : |2) start only ONE core that has NOT been the former leader. …… |Result: loop in Running recovery... this only one core will be the leader finally. this will take a long time cause the waitForReplicasComeup() will end for timeout. this core will cancelRecovery() after he is the leader. it wouldn't run in loop cause cancelRecovery() will stop recovery thread. But before this core become the leader the recovery thread try to connect to old leader and do recovery. recovery thread will throw a lot of exceptions along this process duo to the dead leader. it's fine since the recovery thread will die too |Second Problem (might be the at least similar): live zookeeper is a precondition of solr cluster and also the zookeeper service must ready before start a solr instance. you'd better use zookeeper service separately SolrCloud leader election on single node stucks the initialization -- Key: SOLR-3993 URL: https://issues.apache.org/jira/browse/SOLR-3993 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: Windows 7, Tomcat 6 Reporter: Alexey Kudinov Assignee: Mark Miller Fix For: 4.1, 5.0 setup: 1 node, 4 cores, 2 shards. 15 documents indexed. problem: init stage times out. probable cause: According to the init flow, cores are initialized one by one synchronously. Actually, the main thread waits ShardLeaderElectionContext.waitForReplicasToComeUp until retry threshold, while replica cores are not yet initialized, in other words there is no chance other replicas go up in the meanwhile. stack trace: Thread [main] (Suspended) owns: HashMapK,V (id=3876) owns: StandardContext (id=3877) owns: HashMapK,V (id=3878) owns: StandardHost (id=3879) owns: StandardEngine (id=3880) owns: Service[] (id=3881) Thread.sleep(long) line: not available [native method] ShardLeaderElectionContext.waitForReplicasToComeUp(boolean, String) line: 298 ShardLeaderElectionContext.runLeaderProcess(boolean) line: 143 LeaderElector.runIamLeaderProcess(ElectionContext, boolean) line: 152 LeaderElector.checkIfIamLeader(int, ElectionContext, boolean) line: 96 LeaderElector.joinElection(ElectionContext) line: 262 ZkController.joinElection(CoreDescriptor, boolean) line: 733 ZkController.register(String, CoreDescriptor, boolean, boolean) line: 566 ZkController.register(String, CoreDescriptor) line: 532 CoreContainer.registerInZk(SolrCore) line: 709 CoreContainer.register(String, SolrCore, boolean) line: 693 CoreContainer.load(String, InputSource) line: 535 CoreContainer.load(String, File) line: 356 CoreContainer$Initializer.initialize() line: 308 SolrDispatchFilter.init(FilterConfig) line: 107 ApplicationFilterConfig.getFilter() line: 295 ApplicationFilterConfig.setFilterDef(FilterDef) line: 422 ApplicationFilterConfig.init(Context, FilterDef) line: 115 StandardContext.filterStart() line: 4072 StandardContext.start() line: 4726 StandardHost(ContainerBase).addChildInternal(Container) line: 799 StandardHost(ContainerBase).addChild(Container) line: 779 StandardHost.addChild(Container) line: 601 HostConfig.deployDescriptor(String, File, String) line: 675 HostConfig.deployDescriptors(File, String[]) line: 601 HostConfig.deployApps() line: 502 HostConfig.start() line: 1317 HostConfig.lifecycleEvent(LifecycleEvent) line: 324 LifecycleSupport.fireLifecycleEvent(String, Object) line: 142 StandardHost(ContainerBase).start() line: 1065 StandardHost.start() line: 840 StandardEngine(ContainerBase).start() line: 1057 StandardEngine.start() line: 463 StandardService.start() line: 525 StandardServer.start() line: 754 Catalina.start() line: 595 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available Method.invoke(Object, Object...) line: not available Bootstrap.start() line: 289 Bootstrap.main(String[]) line: 414 After a while, the session times out and following exception appears: Oct 25, 2012 1:16:56 PM
[jira] [Commented] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working
[ https://issues.apache.org/jira/browse/SOLR-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501663#comment-13501663 ] Po Rui commented on SOLR-3859: -- this is a big problem. we also encounter this problem frequently SolrCloud admin graph is showing leader as state recovery failed, but it's working -- Key: SOLR-3859 URL: https://issues.apache.org/jira/browse/SOLR-3859 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux/centos Reporter: Jim Musil Assignee: Mark Miller Fix For: 4.1, 5.0 Attachments: zkAdminScreen.PNG, zkDump.txt I'm not sure this is truly a bug, but the behavior really confuses me. I have four servers running one of my cores. As a test, I took down the leader to watch how leader election works. In this case, a leader was selected, but it went into a state of recovery failed. The odd thing is that everything still works. I can query that box directly and I can query the cluster and I observe correct behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
Po Rui created SOLR-4098: Summary: Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly Key: SOLR-4098 URL: https://issues.apache.org/jira/browse/SOLR-4098 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0, 4.0-BETA, 4.0-ALPHA Reporter: Po Rui Priority: Critical Fix For: 4.0, 4.0-BETA, 4.0-ALPHA a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4098) Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly
[ https://issues.apache.org/jira/browse/SOLR-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4098: - Attachment: SOLR-4098.patch Unacceptable Corecontainer logic.lead delete/rename/swap a core quietly --- Key: SOLR-4098 URL: https://issues.apache.org/jira/browse/SOLR-4098 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4098.patch a bad logic in CoreContainer. it will assign a default name using checkDefault(name) while the core name is not specified. e.g. http://127.0.0.1:8983/solr/admin/cores?action=UNLOAD or append whatever uncrect param like: http://127.0.0.1:8983/solr/admin/cores?action=UNLOADappname=wop those request both unload the core collection1(cause the default core name is collection1 in solr) this bad behavior appear on reload/swap/rename/remove and getCore(String) operation here, checkDefault() should throw exception rather than assign a name quietly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4070) OverSeerCollectionProcessor.createCollection() parameters issue.
[ https://issues.apache.org/jira/browse/SOLR-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4070: - Attachment: SOLR-4070.patch OverSeerCollectionProcessor.createCollection() parameters issue. -- Key: SOLR-4070 URL: https://issues.apache.org/jira/browse/SOLR-4070 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 Attachments: SOLR-4070.patch parameters doesn't validate. the same collectionName may be created more than once. check the existent collectionName and nonexistent config files before create a collection -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4070) OverSeerCollectionProcessor.createCollection() parameters issue.
[ https://issues.apache.org/jira/browse/SOLR-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4070: - Attachment: (was: SOLR-4070.patch) OverSeerCollectionProcessor.createCollection() parameters issue. -- Key: SOLR-4070 URL: https://issues.apache.org/jira/browse/SOLR-4070 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 Attachments: SOLR-4070.patch parameters doesn't validate. the same collectionName may be created more than once. check the existent collectionName and nonexistent config files before create a collection -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4071) CollectionsHandler.handleCreateAction() doesn't validate parameter count and type
[
https://issues.apache.org/jira/browse/SOLR-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497881#comment-13497881
]
Po Rui commented on SOLR-4071:
--
yes. the null object got by SolrQueryRequest.getParams().get() will write into
ZkNodeProps as a String null in Handler. e.g.
request:http://127.0.0.1:8983/solr/admin/collections?action=CREATEname=collection2numShards=3numReplicas=2.
this request miss parameter 'collection.configName'. but the finally message
offer to distributed queue(/overseer/queque) like
{……
name : collection2;
numShards : 3;
collection.configName : null;
……
}
the String 'null' become the default value. all other args in any message maybe
potentially assigned to value null
CollectionsHandler.handleCreateAction() doesn't validate parameter count and
type
-
Key: SOLR-4071
URL: https://issues.apache.org/jira/browse/SOLR-4071
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0-BETA, 4.0
Reporter: Po Rui
Assignee: Mark Miller
Priority: Critical
Fix For: 4.1, 5.0
Attachments: SOLR-4071.patch
CollectionsHandler.handleCreateAction() doesn't validate parameter count and
type. numShards's type doesn't checked and parameter count maybe less than
required
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4071) CollectionsHandler.handleCreateAction() doesn't validate parameter count and type
Po Rui created SOLR-4071: Summary: CollectionsHandler.handleCreateAction() doesn't validate parameter count and type Key: SOLR-4071 URL: https://issues.apache.org/jira/browse/SOLR-4071 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0, 4.0-BETA Reporter: Po Rui Priority: Critical Fix For: 4.0, 4.0-BETA CollectionsHandler.handleCreateAction() doesn't validate parameter count and type. numShards's type doesn't checked and parameter count maybe less than required -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4071) CollectionsHandler.handleCreateAction() doesn't validate parameter count and type
[ https://issues.apache.org/jira/browse/SOLR-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4071: - Attachment: SOLR-4071.patch CollectionsHandler.handleCreateAction() doesn't validate parameter count and type - Key: SOLR-4071 URL: https://issues.apache.org/jira/browse/SOLR-4071 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-BETA, 4.0 Attachments: SOLR-4071.patch CollectionsHandler.handleCreateAction() doesn't validate parameter count and type. numShards's type doesn't checked and parameter count maybe less than required -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4071) CollectionsHandler.handleCreateAction() doesn't validate parameter count and type
[ https://issues.apache.org/jira/browse/SOLR-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496077#comment-13496077 ] Po Rui edited comment on SOLR-4071 at 11/13/12 10:26 AM: - CollectionHandler validate parameter count and type OverseerCollectionProcessor validate existent collection name and nonexistent config path was (Author: brui): CollectionHandler validate parameter count and type OverseerCollectionProcessor validate existed collection name and config path CollectionsHandler.handleCreateAction() doesn't validate parameter count and type - Key: SOLR-4071 URL: https://issues.apache.org/jira/browse/SOLR-4071 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Priority: Critical Fix For: 4.0-BETA, 4.0 Attachments: SOLR-4071.patch CollectionsHandler.handleCreateAction() doesn't validate parameter count and type. numShards's type doesn't checked and parameter count maybe less than required -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4070) OverSeerCollectionProcessor.createCollection() parameters issue.
[ https://issues.apache.org/jira/browse/SOLR-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4070: - Description: parameters doesn't validate. the same collectionName may be created more than once. check the existent collectionName and nonexistent config files before create a collection (was: parameters doesn't validate. the same collectionName may be created more than once. need parameter validate.) OverSeerCollectionProcessor.createCollection() parameters issue. -- Key: SOLR-4070 URL: https://issues.apache.org/jira/browse/SOLR-4070 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-BETA, 4.0 Attachments: SOLR-4070.patch parameters doesn't validate. the same collectionName may be created more than once. check the existent collectionName and nonexistent config files before create a collection -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4069) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate
Po Rui created SOLR-4069: Summary: ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate Key: SOLR-4069 URL: https://issues.apache.org/jira/browse/SOLR-4069 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0, 4.0-BETA, 4.0-ALPHA Reporter: Po Rui Fix For: 4.0, 4.0-BETA, 4.0-ALPHA ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4069) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate
[ https://issues.apache.org/jira/browse/SOLR-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4069: - Attachment: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- Key: SOLR-4069 URL: https://issues.apache.org/jira/browse/SOLR-4069 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4069) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate
[ https://issues.apache.org/jira/browse/SOLR-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4069: - Attachment: (was: SOLR-4069.patch) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- Key: SOLR-4069 URL: https://issues.apache.org/jira/browse/SOLR-4069 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4069) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate
[ https://issues.apache.org/jira/browse/SOLR-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4069: - Attachment: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- Key: SOLR-4069 URL: https://issues.apache.org/jira/browse/SOLR-4069 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4069) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate
[ https://issues.apache.org/jira/browse/SOLR-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4069: - Attachment: (was: SOLR-4069.patch) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- Key: SOLR-4069 URL: https://issues.apache.org/jira/browse/SOLR-4069 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4069) ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate
[ https://issues.apache.org/jira/browse/SOLR-4069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4069: - Attachment: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- Key: SOLR-4069 URL: https://issues.apache.org/jira/browse/SOLR-4069 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4069.patch ShardLeaderElectionContext.rejoinLeaderElection() doesn't clear the leader in clusterstate -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4070) OverSeerCollectionProcessor.createCollection() parameters issue.
Po Rui created SOLR-4070: Summary: OverSeerCollectionProcessor.createCollection() parameters issue. Key: SOLR-4070 URL: https://issues.apache.org/jira/browse/SOLR-4070 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0, 4.0-BETA Reporter: Po Rui Fix For: 4.0, 4.0-BETA Attachments: SOLR-4070.patch parameters doesn't validate. the same collectionName may be created more than once. need parameter validate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4070) OverSeerCollectionProcessor.createCollection() parameters issue.
[ https://issues.apache.org/jira/browse/SOLR-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4070: - Attachment: SOLR-4070.patch OverSeerCollectionProcessor.createCollection() parameters issue. -- Key: SOLR-4070 URL: https://issues.apache.org/jira/browse/SOLR-4070 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-BETA, 4.0 Attachments: SOLR-4070.patch parameters doesn't validate. the same collectionName may be created more than once. need parameter validate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4064) ShardLeaderElectionContext's function parameter error
Po Rui created SOLR-4064: Summary: ShardLeaderElectionContext's function parameter error Key: SOLR-4064 URL: https://issues.apache.org/jira/browse/SOLR-4064 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0, 4.0-BETA, 4.0-ALPHA Reporter: Po Rui Fix For: 4.0, 4.0-BETA, 4.0-ALPHA -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4064) ShardLeaderElectionContext's function parameter error
[ https://issues.apache.org/jira/browse/SOLR-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4064: - Description: function runLeaderProcess(boolean) of calss ShardLeaderElectionContext contains a rejionLeaderElection() invoke with wrong parameter rejoinLeaderElection(coreName, core). the parameter should be rejoinLeaderElection(leaderSeqPath, core) ShardLeaderElectionContext's function parameter error - Key: SOLR-4064 URL: https://issues.apache.org/jira/browse/SOLR-4064 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 function runLeaderProcess(boolean) of calss ShardLeaderElectionContext contains a rejionLeaderElection() invoke with wrong parameter rejoinLeaderElection(coreName, core). the parameter should be rejoinLeaderElection(leaderSeqPath, core) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4064) ShardLeaderElectionContext's function parameter error
[ https://issues.apache.org/jira/browse/SOLR-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4064: - Attachment: SOLR-4064.patch ShardLeaderElectionContext's function parameter error - Key: SOLR-4064 URL: https://issues.apache.org/jira/browse/SOLR-4064 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Po Rui Fix For: 4.0-ALPHA, 4.0-BETA, 4.0 Attachments: SOLR-4064.patch function runLeaderProcess(boolean) of calss ShardLeaderElectionContext contains a rejionLeaderElection() invoke with wrong parameter rejoinLeaderElection(coreName, core). the parameter should be rejoinLeaderElection(leaderSeqPath, core) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4034) creating a collection with a existed collection name in the cluster act wrongly
Po Rui created SOLR-4034: Summary: creating a collection with a existed collection name in the cluster act wrongly Key: SOLR-4034 URL: https://issues.apache.org/jira/browse/SOLR-4034 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0, 4.0-BETA Reporter: Po Rui Fix For: 4.0, 4.0-BETA sometimes succeed but sometimes failed when request to create a collection whose name is taken in the cluster . Doesn't check the collection name before create it lead to this error(unstable). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4034) creating a collection with a existed collection name in the cluster act wrongly
[ https://issues.apache.org/jira/browse/SOLR-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4034: - Attachment: SOLR-4034.patch creating a collection with a existed collection name in the cluster act wrongly Key: SOLR-4034 URL: https://issues.apache.org/jira/browse/SOLR-4034 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Labels: collection, create, overseer Fix For: 4.0-BETA, 4.0 Attachments: SOLR-4034.patch sometimes succeed but sometimes failed when request to create a collection whose name is taken in the cluster . Doesn't check the collection name before create it lead to this error(unstable). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4015) the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number
Po Rui created SOLR-4015: Summary: the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number Key: SOLR-4015 URL: https://issues.apache.org/jira/browse/SOLR-4015 Project: Solr Issue Type: Bug Affects Versions: 4.0, 4.0-BETA Reporter: Po Rui Fix For: 4.0, 4.0-BETA the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number.EX. the cluster have 5 avalaible solr-nodes. than user want create a collection with API param numShards=2numReplicas=2. this will lead to a collection contained 2 shards but one own 2 replicas and another own 1 replica. More serious, this will lead a collection loss one shard while the API param is numShards=3numReplicas=2. this will confuse the user. this incomplete collection will confuse the user. so we should discard the colletion create action while the numLivedNode numShards * (numReplicas + 1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4015) the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number
[ https://issues.apache.org/jira/browse/SOLR-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4015: - Attachment: OverseerCollectionProcessor.java the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number --- Key: SOLR-4015 URL: https://issues.apache.org/jira/browse/SOLR-4015 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Labels: collction Fix For: 4.0-BETA, 4.0 Attachments: OverseerCollectionProcessor.java the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number.EX. the cluster have 5 avalaible solr-nodes. than user want create a collection with API param numShards=2numReplicas=2. this will lead to a collection contained 2 shards but one own 2 replicas and another own 1 replica. More serious, this will lead a collection loss one shard while the API param is numShards=3numReplicas=2. this will confuse the user. this incomplete collection will confuse the user. so we should discard the colletion create action while the numLivedNode numShards * (numReplicas + 1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4015) the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number
[ https://issues.apache.org/jira/browse/SOLR-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4015: - Attachment: (was: OverseerCollectionProcessor.java) the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number --- Key: SOLR-4015 URL: https://issues.apache.org/jira/browse/SOLR-4015 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Labels: collction Fix For: 4.0-BETA, 4.0 the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number.EX. the cluster have 5 avalaible solr-nodes. than user want create a collection with API param numShards=2numReplicas=2. this will lead to a collection contained 2 shards but one own 2 replicas and another own 1 replica. More serious, this will lead a collection loss one shard while the API param is numShards=3numReplicas=2. this will confuse the user. this incomplete collection will confuse the user. so we should discard the colletion create action while the numLivedNode numShards * (numReplicas + 1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4015) the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number
[ https://issues.apache.org/jira/browse/SOLR-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4015: - Attachment: OverseerCollectionProcessor.java the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number --- Key: SOLR-4015 URL: https://issues.apache.org/jira/browse/SOLR-4015 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Labels: collction Fix For: 4.0-BETA, 4.0 Attachments: OverseerCollectionProcessor.java the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number.EX. the cluster have 5 avalaible solr-nodes. than user want create a collection with API param numShards=2numReplicas=2. this will lead to a collection contained 2 shards but one own 2 replicas and another own 1 replica. More serious, this will lead a collection loss one shard while the API param is numShards=3numReplicas=2. this will confuse the user. this incomplete collection will confuse the user. so we should discard the colletion create action while the numLivedNode numShards * (numReplicas + 1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4015) the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number
[ https://issues.apache.org/jira/browse/SOLR-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Po Rui updated SOLR-4015: - Attachment: SOLR_4015-OverseerCollectionProcessor.patch the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number --- Key: SOLR-4015 URL: https://issues.apache.org/jira/browse/SOLR-4015 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA, 4.0 Reporter: Po Rui Labels: collction Fix For: 4.0-BETA, 4.0 Attachments: OverseerCollectionProcessor.java, SOLR_4015-OverseerCollectionProcessor.patch the collection create AIP may create a collection that user not expected when the solr-nodes number less than the request collection's replicas number.EX. the cluster have 5 avalaible solr-nodes. than user want create a collection with API param numShards=2numReplicas=2. this will lead to a collection contained 2 shards but one own 2 replicas and another own 1 replica. More serious, this will lead a collection loss one shard while the API param is numShards=3numReplicas=2. this will confuse the user. this incomplete collection will confuse the user. so we should discard the colletion create action while the numLivedNode numShards * (numReplicas + 1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
