[ 
https://issues.apache.org/jira/browse/SOLR-13210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

Reply via email to