[jira] [Commented] (SOLR-13210) TriLevelCompositeIdRoutingTest makes no sense -- can never fail
[ https://issues.apache.org/jira/browse/SOLR-13210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762181#comment-16762181 ] ASF subversion and git services commented on SOLR-13210: Commit 69b5a04a4dfc9684554b5fde82f1107d006847a1 in lucene-solr's branch refs/heads/branch_8x from Chris M. Hostetter [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=69b5a04 ] SOLR-13210: Fix TriLevelCompositeIdRoutingTest to actually make sense (cherry picked from commit 87ad59f826d3ea5ea0e6239397c1d9a8acf59323) > TriLevelCompositeIdRoutingTest makes no sense -- can never fail > --- > > Key: SOLR-13210 > URL: https://issues.apache.org/jira/browse/SOLR-13210 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > Attachments: SOLR-13210.patch, > SOLR-13210_demonstrate_broken_test.patch > > > i recently fixed tweaked TriLevelCompositeIdRoutingTest to lower the > node/shard count on TEST_NIGHTLY because it was constantly causing an OOM. > While skimming this test i realized that (other then the OOM, or other > catastrophic failure in solr) it was garunteed to never fail, rgardless of > what bugs might exist in solr when routing an update/query: > * it doesn't sanity check that any docs are returned from any query -- so if > commit does nothing and it gets no results from each of the shard queries, it > will still pass > * the {{getKey()}} method -- which throws away anything after the last "!" in > a String -- is called redundently on it's own output to populate an {{idMap}} > ... but not before the first result is used do to acontainsKey assertion on > that same {{idMap}} > ** ie: if {{app42/7!user33!doc1234}} is a uniqueKey value, then > {{app42/7!user33}} is what the assert !containsKey checks the Map for, but > {{app42/7}} is what gets put in the Map -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13210) TriLevelCompositeIdRoutingTest makes no sense -- can never fail
[ https://issues.apache.org/jira/browse/SOLR-13210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762166#comment-16762166 ] ASF subversion and git services commented on SOLR-13210: Commit 87ad59f826d3ea5ea0e6239397c1d9a8acf59323 in lucene-solr's branch refs/heads/master from Chris M. Hostetter [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=87ad59f ] SOLR-13210: Fix TriLevelCompositeIdRoutingTest to actually make sense > TriLevelCompositeIdRoutingTest makes no sense -- can never fail > --- > > Key: SOLR-13210 > URL: https://issues.apache.org/jira/browse/SOLR-13210 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > Attachments: SOLR-13210.patch, > SOLR-13210_demonstrate_broken_test.patch > > > i recently fixed tweaked TriLevelCompositeIdRoutingTest to lower the > node/shard count on TEST_NIGHTLY because it was constantly causing an OOM. > While skimming this test i realized that (other then the OOM, or other > catastrophic failure in solr) it was garunteed to never fail, rgardless of > what bugs might exist in solr when routing an update/query: > * it doesn't sanity check that any docs are returned from any query -- so if > commit does nothing and it gets no results from each of the shard queries, it > will still pass > * the {{getKey()}} method -- which throws away anything after the last "!" in > a String -- is called redundently on it's own output to populate an {{idMap}} > ... but not before the first result is used do to acontainsKey assertion on > that same {{idMap}} > ** ie: if {{app42/7!user33!doc1234}} is a uniqueKey value, then > {{app42/7!user33}} is what the assert !containsKey checks the Map for, but > {{app42/7}} is what gets put in the Map -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13210) TriLevelCompositeIdRoutingTest makes no sense -- can never fail
[ https://issues.apache.org/jira/browse/SOLR-13210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761474#comment-16761474 ] Lucene/Solr QA commented on SOLR-13210: --- | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || || || || || {color:brown} Prechecks {color} || | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 1 new or modified test files. {color} | || || || || {color:brown} master Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 43s{color} | {color:green} master passed {color} | || || || || {color:brown} Patch Compile Tests {color} || | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 29s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 29s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Release audit (RAT) {color} | {color:green} 1m 29s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Check forbidden APIs {color} | {color:green} 1m 29s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} Validate source patterns {color} | {color:green} 1m 29s{color} | {color:green} the patch passed {color} | || || || || {color:brown} Other Tests {color} || | {color:green}+1{color} | {color:green} unit {color} | {color:green} 39m 2s{color} | {color:green} core in the patch passed. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 44m 41s{color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | SOLR-13210 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12957562/SOLR-13210.patch | | Optional Tests | compile javac unit ratsources checkforbiddenapis validatesourcepatterns | | uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | ant | | Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh | | git revision | master / 1b077cf | | ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 | | Default Java | 1.8.0_191 | | Test Results | https://builds.apache.org/job/PreCommit-SOLR-Build/294/testReport/ | | modules | C: solr/core U: solr/core | | Console output | https://builds.apache.org/job/PreCommit-SOLR-Build/294/console | | Powered by | Apache Yetus 0.7.0 http://yetus.apache.org | This message was automatically generated. > TriLevelCompositeIdRoutingTest makes no sense -- can never fail > --- > > Key: SOLR-13210 > URL: https://issues.apache.org/jira/browse/SOLR-13210 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > Attachments: SOLR-13210.patch, > SOLR-13210_demonstrate_broken_test.patch > > > i recently fixed tweaked TriLevelCompositeIdRoutingTest to lower the > node/shard count on TEST_NIGHTLY because it was constantly causing an OOM. > While skimming this test i realized that (other then the OOM, or other > catastrophic failure in solr) it was garunteed to never fail, rgardless of > what bugs might exist in solr when routing an update/query: > * it doesn't sanity check that any docs are returned from any query -- so if > commit does nothing and it gets no results from each of the shard queries, it > will still pass > * the {{getKey()}} method -- which throws away anything after the last "!" in > a String -- is called redundently on it's own output to populate an {{idMap}} > ... but not before the first result is used do to acontainsKey assertion on > that same {{idMap}} > ** ie: if {{app42/7!user33!doc1234}} is a uniqueKey value, then > {{app42/7!user33}} is what the assert !containsKey checks the Map for, but > {{app42/7}} is what gets put in the Map -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13210) TriLevelCompositeIdRoutingTest makes no sense -- can never fail
[ https://issues.apache.org/jira/browse/SOLR-13210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760070#comment-16760070 ] Shalin Shekhar Mangar commented on SOLR-13210: -- I myself don't know because I committed it years ago (and someone else wrote the original test). But looking at the logic of extracting the key (throwing away everything after the last `!`), I think the idMap is supposed to have `app!user`. The test is making wrong assumptions about the shard distribution. I think what we need to test here is that: # Given a fixed number of apps and users, all data for the same {{app!user}} prefix go to the same shard in the absence of masks # Choose a mask such that the {{app}} spans multiple shards but verify that any given {{app!user}} prefix goes to a single/same shard only > TriLevelCompositeIdRoutingTest makes no sense -- can never fail > --- > > Key: SOLR-13210 > URL: https://issues.apache.org/jira/browse/SOLR-13210 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > Attachments: SOLR-13210_demonstrate_broken_test.patch > > > i recently fixed tweaked TriLevelCompositeIdRoutingTest to lower the > node/shard count on TEST_NIGHTLY because it was constantly causing an OOM. > While skimming this test i realized that (other then the OOM, or other > catastrophic failure in solr) it was garunteed to never fail, rgardless of > what bugs might exist in solr when routing an update/query: > * it doesn't sanity check that any docs are returned from any query -- so if > commit does nothing and it gets no results from each of the shard queries, it > will still pass > * the {{getKey()}} method -- which throws away anything after the last "!" in > a String -- is called redundently on it's own output to populate an {{idMap}} > ... but not before the first result is used do to acontainsKey assertion on > that same {{idMap}} > ** ie: if {{app42/7!user33!doc1234}} is a uniqueKey value, then > {{app42/7!user33}} is what the assert !containsKey checks the Map for, but > {{app42/7}} is what gets put in the Map -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org