[
https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-5652:
---------------------------
Attachment: bin_dv.post-patch.log.txt
Using my patch, my laptop hammered out 154 iterations of all the cursor tests
last night before encountering a failure -- but this smells like it might be a
completely different bug.
In particular:
* the sort is "bin_dv desc" -- note that sort missing last/first isn't used
* the "bin_dv asc" sort works fine, and produces the exact reverse sort of as
"bin_dv desc" -- except that with the desc sort, after the last doc (id=5) is
returned, the next cursor call generates a response consisting of that last doc
again.
Details...
trunk 1561765M
heres the seed (which doesn't reproduce for me) and failure details...
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=DistribCursorPagingTest -Dtests.method=testDistribSearch
-Dtests.seed=A98D5436D5ABD5E2 -Dtests.slow=true -Dtests.locale=lt_LT
-Dtests.timezone=IET -Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 30.8s J0 | DistribCursorPagingTest.testDistribSearch <<<
[junit4] > Throwable #1: java.lang.AssertionError:
({params(q=*%3A*&fl=id%2Cbin_dv&rows=30&sort=bin_dv+desc%2C+id+desc),defaults(cursorMark=AoIgRQ%3D%3D)})
walk already seen: 5, don't know why; q=id:5 gives:
{responseHeader={status=0,QTime=10},response={numFound=1,start=0,maxScore=4.8607297,docs=[SolrDocument{id=5,
int=472194186, int_last=472194186, int_first=472194186, int_dv=472194186,
int_dv_last=472194186, int_dv_first=472194186, long=9045528501943660239,
long_last=9045528501943660239, long_first=9045528501943660239,
long_dv=9045528501943660239, long_dv_last=9045528501943660239,
long_dv_first=9045528501943660239, double=-1.0261364741663126E9,
double_last=-1.0261364741663126E9, double_first=-1.0261364741663126E9,
double_dv=-1.0261364741663126E9, double_dv_last=-1.0261364741663126E9,
double_dv_first=-1.0261364741663126E9, str=𐬿, str_last=𐬿, str_first=𐬿,
str_dv=𐬿, str_dv_last=𐬿, str_dv_first=𐬿, _version_=1458455185121607680}]}}
[junit4] > at
__randomizedtesting.SeedInfo.seed([A98D5436D5ABD5E2:286BDA2EA2F4B5DE]:0)
[junit4] > at
org.apache.solr.cloud.DistribCursorPagingTest.assertFullWalkNoDups(DistribCursorPagingTest.java:760)
[junit4] > at
org.apache.solr.cloud.DistribCursorPagingTest.doRandomSortsOnLargeIndex(DistribCursorPagingTest.java:542)
[junit4] > at
org.apache.solr.cloud.DistribCursorPagingTest.doTest(DistribCursorPagingTest.java:91)
[junit4] > at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:867)
[junit4] > at java.lang.Thread.run(Thread.java:724)
{noformat}
I'm going to go ahead and commit & backport the patch since we know it's needed
for the sortMissing docvalues stuff -- but in the meantime, if anyone can help
brainstorm possible causes for this slightly new variant that would certainly
be helpful
> Heisenbug in DistribCursorPagingTest: "walk already seen ..."
> -------------------------------------------------------------
>
> Key: SOLR-5652
> URL: https://issues.apache.org/jira/browse/SOLR-5652
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: 129.log, 372.log, SOLR-5652.codec.skip.dv.patch,
> SOLR-5652.nocommit.patch, SOLR-5652.patch, bin_dv.post-patch.log.txt,
> jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1200.log.txt,
> jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1217.log.txt
>
>
> Several times now, Uwe's jenkins has encountered a "walk already seen ..."
> assertion failure from DistribCursorPagingTest that I've been unable to
> fathom, let alone reproduce (although sarowe was able to trigger a similar,
> non-reproducible seed, failure on his machine)
> Using this as a tracking issue to try and make sense of it.
> Summary of things noticed so far:
> * So far only seen on http://jenkins.thetaphi.de & sarowe's mac
> * So far seen on MacOSX and Linux
> * So far seen on branch 4x and trunk
> * So far seen on Java6, Java7, and Java8
> * fails occured in first block of randomized testing:
> ** we've indexed a small number of randomized docs
> ** we're explicitly looping over every field and sorting in both directions
> * fails were sorting on one of the "\*_dv_last" or "\*_dv_first" fields
> (docValues=true, either sortMissingLast=true OR sortMissingFirst=true)
> ** for desc sorts, sort on same field asc has worked fine just before this
> (fields are in arbitrary order, but "asc" always tried before "desc")
> ** sorting on some other random fields has sometimes been tried before this
> and worked
> (specifics of each failure seen in the wild recorded in comments)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
