[
https://issues.apache.org/jira/browse/SOLR-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812180#comment-16812180
]
Shalin Shekhar Mangar commented on SOLR-13369:
----------------------------------------------
My understanding in the case of {{app9/2!user32!doc58}} is that:
* 2 bits are taken from the 32 bit hash of app9
* 8 bits are taken from the 32 bit hash of user32
* 22 bits are taken from the 32 bit hash of doc58
Going back to what you wrote in SOLR-13210, I think you're right. When the bits
is specified neither app nor app!user is guaranteed to be limited to a single
shard. I don't really understand this router very well. Perhaps [~anshumg] can
help?
> TriLevelCompositeIdRoutingTest failure: same route prefix maped to multiple
> shards
> ----------------------------------------------------------------------------------
>
> Key: SOLR-13369
> URL: https://issues.apache.org/jira/browse/SOLR-13369
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Priority: Major
> Attachments:
> TriLevelCompositeIdRoutingTest-failure-with-debug-log.txt,
> thetaphi_Lucene-Solr-8.x-Linux_342.log.txt
>
>
> thetaphi's 8x jenkins job just identified a reproducing seed that causes
> TriLevelCompositeIdRoutingTest to fail after detecting 2 docs with matching
> route prefixes on different shards...
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TriLevelCompositeIdRoutingTest -Dtests.method=test
> -Dtests.seed=A6B6F0104FE6018F -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=sr-Latn -Dtests.timezone=Pacific/Tongatapu
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 9.38s J0 | TriLevelCompositeIdRoutingTest.test <<<
> [junit4] > Throwable #1: org.junit.ComparisonFailure: routePrefix
> app9/2!user32 found in multiple shards expected:<shard[3]> but was:<shard[2]>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([A6B6F0104FE6018F:2EE2CFCAE11A6C77]:0)
> [junit4] > at
> org.apache.solr.cloud.TriLevelCompositeIdRoutingTest.test(TriLevelCompositeIdRoutingTest.java:122)
> {noformat}
> It's possible this is just a bug I introduced in SOLR-13210 due to a
> missunderstanding in how routePrefixes that use a bit mask (ie: {{/2}} in the
> assertion failure) are expected to work -- but I thought i had that squared
> away based on shalin's feedback in SOLR-13210
--
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
