[
https://issues.apache.org/jira/browse/SOLR-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16521867#comment-16521867
]
Erick Erickson edited comment on SOLR-12513 at 6/25/18 5:42 AM:
----------------------------------------------------------------
Fixing the test is easy enough, just specify maxSegments=1 for the optimize
call at line 156.
change {{assertU(optimize());}} to {{assertU(optimize("maxSegments", "1"));}}.
This does call into question other places where optimize assumes 1 setment, so
I took a quick look through the other calls to assertU(optimize()) and found
several that have comments or it's immediately obvious that they expect exactly
one segment and changed those too.
Along the way I looked at DirectUpdateHandlerOptimizeTest as that called
optimize, and I'm puzzled. The last time that test did anything except test
that calling optimize with -1 threw an error was... 2008.
The assertNumSegments was commented out about then. This change predates
TieredMergePolicy, which doesn't behave the way this test expects anyway. So if
you re-enable assertNumSegments (well, actually use one that doesn't read the
directory over in TestMergePolicyConfig) then the very first assert fails.
Testing the assert failure with a segment count of -1 seems like a good thing
to keep so I'll move if over into TestMergePolicyConfig and delete
DirectUpdateHandlerOptimizeTest. Since it doesn't really care what merge policy
is used, it just needs to be tested once.
There are two mentions in:
..../lucene/tools/junit4/cached-timehints.txt
I'm not familiar with this file, should the references just be removed?
[~steve_rowe] do you know?
Meanwhile I'll beast TestCodecSupport tonight.
was (Author: erickerickson):
Fixing the test is easy enough, just specify maxSegments=1 for the optimize
call at line 156.
change {{assertU(optimize());}} to {{assertU(optimize("maxSegments", "1"));}}.
I took a quick look through the other calls to assertU(optimize()) and found
several that have comments or it's immediately obvious that they expect exactly
one segment and changed those too.
Along the way I looked at DirectUpdateHandlerOptimizeTest as that called
optimize, and I'm puzzled. The last time that test did anything except test
that calling optimize with -1 threw an error was... 2008.
The assertNumSegments was commented out about then. This change predates
TieredMergePolicy, which doesn't behave the way this test expects anyway. So if
you re-enable assertNumSegments (well, actually use one that doesn't read the
directory over in TestMergePolicyConfig) then the very first assert fails.
Testing the assert failure with a segment count of -1 seems like a good thing
to keep so I'll move if over into TestMergePolicyConfig and delete
DirectUpdateHandlerOptimizeTest. Since it doesn't really care what merge policy
is used, it just needs to be tested once.
There are two mentions in:
..../lucene/tools/junit4/cached-timehints.txt
I'm not familiar with this file, should the references just be removed?
[~steve_rowe] do you know?
Meanwhile I'll beast TestCodecSupport tonight.
> Reproducing TestCodecSupport.testMixedCompressionMode failure
> -------------------------------------------------------------
>
> Key: SOLR-12513
> URL: https://issues.apache.org/jira/browse/SOLR-12513
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Steve Rowe
> Assignee: Erick Erickson
> Priority: Major
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7375/]
> (reproduces for me on Linux):
> {noformat}
> Checking out Revision 3b9d3a760a432b97aad2c08b2f778fa2344eb14a
> (refs/remotes/origin/master)
> [...]
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestCodecSupport
> -Dtests.method=testMixedCompressionMode -Dtests.seed=F584376A20EC9B2D
> -Dtests.slow=true -Dtests.locale=ha-GH -Dtests.timezone=Africa/Nairobi
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> [junit4] FAILURE 0.59s J1 | TestCodecSupport.testMixedCompressionMode <<<
> [junit4] > Throwable #1: org.junit.ComparisonFailure: Expecting
> compression mode string to be BEST_SPEED but got: BEST_COMPRESSION
> [junit4] > SegmentInfo: _5(8.0.0):c1
> [junit4] > SegmentInfos: segments_e: _7(8.0.0):c2 _5(8.0.0):c1
> [junit4] > Codec: Lucene70 expected:<BEST_[SPEED]> but
> was:<BEST_[COMPRESSION]>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([F584376A20EC9B2D:2BF1400E658E6E9C]:0)
> [junit4] > at
> org.apache.solr.core.TestCodecSupport.lambda$assertCompressionMode$0(TestCodecSupport.java:115)
> [junit4] > at
> org.apache.solr.core.SolrCore.withSearcher(SolrCore.java:1874)
> [junit4] > at
> org.apache.solr.core.TestCodecSupport.assertCompressionMode(TestCodecSupport.java:112)
> [junit4] > at
> org.apache.solr.core.TestCodecSupport.testMixedCompressionMode(TestCodecSupport.java:157)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at
> java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=1658, maxMBSortInHeap=7.737749859284375,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@2da9a1c5),
> locale=ha-GH, timezone=Africa/Nairobi
> [junit4] 2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 10.0.1
> (64-bit)/cpus=3,threads=1,free=39067800,total=97320960
> {noformat}
--
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
