[jira] [Commented] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
[ https://issues.apache.org/jira/browse/SOLR-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068109#comment-17068109 ] ASF subversion and git services commented on SOLR-14322: Commit a31ecd2eb8c2f1b8b24d0afb7242e71c622378cc in lucene-solr's branch refs/heads/master from Mike Drob [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a31ecd2 ] SOLR-14322 Improve AbstractFullDistribZkTestBase.waitForThingsToLevelOut > AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent > -- > > Key: SOLR-14322 > URL: https://issues.apache.org/jira/browse/SOLR-14322 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mike Drob >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are many strange things going on with this method - > 1. It accepts a value in seconds, but many callers pass millis > 2. The method will only retry on the last shard being inconsistent, not any > other shard > 3. Catching Throwable is dubious. > 4. There's a conditional wait mixed with an unconditional sleep. (this might > be ok?) > 5. There's a bunch of System.out and System.err > 6. If we never get to the "level out state" we still simply return instead of > somehow indicating the error condition -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
[ https://issues.apache.org/jira/browse/SOLR-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068063#comment-17068063 ] Mike Drob commented on SOLR-14322: -- I'll add a note in CHANGES > AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent > -- > > Key: SOLR-14322 > URL: https://issues.apache.org/jira/browse/SOLR-14322 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mike Drob >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are many strange things going on with this method - > 1. It accepts a value in seconds, but many callers pass millis > 2. The method will only retry on the last shard being inconsistent, not any > other shard > 3. Catching Throwable is dubious. > 4. There's a conditional wait mixed with an unconditional sleep. (this might > be ok?) > 5. There's a bunch of System.out and System.err > 6. If we never get to the "level out state" we still simply return instead of > somehow indicating the error condition -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
[ https://issues.apache.org/jira/browse/SOLR-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068059#comment-17068059 ] Chris M. Hostetter commented on SOLR-14322: --- At a glance everything currently in the PR looks sane to me. In theory, since thse are public/protected methods in a public class in the test-framework we should be concerned about back compat for users that are subclassing it to write their own tests, and these method signature changes should be a No-No BUT ... this class & these methods are such a cluster-f*ck already, that if we cause a compilation failure for anyone actaully trying to call these methods in existing code, we'll probably be doing them a favor -- so i'm certainly not going to complain. > AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent > -- > > Key: SOLR-14322 > URL: https://issues.apache.org/jira/browse/SOLR-14322 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mike Drob >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are many strange things going on with this method - > 1. It accepts a value in seconds, but many callers pass millis > 2. The method will only retry on the last shard being inconsistent, not any > other shard > 3. Catching Throwable is dubious. > 4. There's a conditional wait mixed with an unconditional sleep. (this might > be ok?) > 5. There's a bunch of System.out and System.err > 6. If we never get to the "level out state" we still simply return instead of > somehow indicating the error condition -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
[ https://issues.apache.org/jira/browse/SOLR-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066958#comment-17066958 ] Mike Drob commented on SOLR-14322: -- [~hossman] - I tagged you for a review on the PR since you've worked on this class before, if you wouldn't mind taking a look. Most of the change is pretty straightforward but I would appreciate an extra set of eyes on it. > AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent > -- > > Key: SOLR-14322 > URL: https://issues.apache.org/jira/browse/SOLR-14322 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mike Drob >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are many strange things going on with this method - > 1. It accepts a value in seconds, but many callers pass millis > 2. The method will only retry on the last shard being inconsistent, not any > other shard > 3. Catching Throwable is dubious. > 4. There's a conditional wait mixed with an unconditional sleep. (this might > be ok?) > 5. There's a bunch of System.out and System.err > 6. If we never get to the "level out state" we still simply return instead of > somehow indicating the error condition -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
