You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2018/06/25 05:43:00 UTC
[jira] [Comment Edited] (SOLR-12513) Reproducing
TestCodecSupport.testMixedCompressionMode failure
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org