[jira] [Assigned] (SOLR-12522) Support a runtime function `#ALL` for 'replica' in autoscaling policies
[
https://issues.apache.org/jira/browse/SOLR-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-12522:
-
Assignee: Noble Paul
> Support a runtime function `#ALL` for 'replica' in autoscaling policies
> ---
>
> Key: SOLR-12522
> URL: https://issues.apache.org/jira/browse/SOLR-12522
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> today we have to use the convoluted rule to place all TLOG replicas in nodes
> with ssd disk
> {code}
> { "replica": 0, "diskType" : "!ssd", "type" : "TLOG" }
> {code}
> Ideally it should be expressed better as
> {code}
> { "replica": "#ALL", "diskType" : "ssd", "type" : "TLOG" }
> {code}
--
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
[jira] [Commented] (SOLR-12522) Support a runtime function `#ALL` for 'replica' in autoscaling policies
[
https://issues.apache.org/jira/browse/SOLR-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546053#comment-16546053
]
ASF subversion and git services commented on SOLR-12522:
Commit 49b1fe2b6d4213e3d9033eeeccaa5a7e6d8050f8 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49b1fe2 ]
SOLR-12522: Support a runtime function `#ALL` for 'replica' in autoscaling
policies
> Support a runtime function `#ALL` for 'replica' in autoscaling policies
> ---
>
> Key: SOLR-12522
> URL: https://issues.apache.org/jira/browse/SOLR-12522
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Noble Paul
>Priority: Major
>
> today we have to use the convoluted rule to place all TLOG replicas in nodes
> with ssd disk
> {code}
> { "replica": 0, "diskType" : "!ssd", "type" : "TLOG" }
> {code}
> Ideally it should be expressed better as
> {code}
> { "replica": "#ALL", "diskType" : "ssd", "type" : "TLOG" }
> {code}
--
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
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10.0.1) - Build # 2335 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2335/
Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir
Error Message:
Captured an uncaught exception in thread: Thread[id=12003,
name=cdcr-replicator-4682-thread-1, state=RUNNABLE,
group=TGRP-CdcrBidirectionalTest]
Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=12003, name=cdcr-replicator-4682-thread-1,
state=RUNNABLE, group=TGRP-CdcrBidirectionalTest]
Caused by: java.lang.AssertionError: 1606206509417496576 != 1606206508916277248
at __randomizedtesting.SeedInfo.seed([DC1C2C3F7FA2E766]:0)
at
org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611)
at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125)
at
org.apache.solr.handler.CdcrReplicatorScheduler.lambda$start$0(CdcrReplicatorScheduler.java:81)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)
Build Log:
[...truncated 13502 lines...]
[junit4] Suite: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest
[junit4] 2> Creating dataDir:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.cdcr.CdcrBidirectionalTest_DC1C2C3F7FA2E766-001/init-core-data-001
[junit4] 2> 764763 WARN
(SUITE-CdcrBidirectionalTest-seed#[DC1C2C3F7FA2E766]-worker) []
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=30 numCloses=30
[junit4] 2> 764763 INFO
(SUITE-CdcrBidirectionalTest-seed#[DC1C2C3F7FA2E766]-worker) []
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false)
w/NUMERIC_DOCVALUES_SYSPROP=false
[junit4] 2> 764764 INFO
(SUITE-CdcrBidirectionalTest-seed#[DC1C2C3F7FA2E766]-worker) []
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via:
@org.apache.solr.util.RandomizeSSL(reason="", ssl=0.0/0.0, value=0.0/0.0,
clientAuth=0.0/0.0)
[junit4] 2> 764764 INFO
(SUITE-CdcrBidirectionalTest-seed#[DC1C2C3F7FA2E766]-worker) []
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks:
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
[junit4] 2> 764765 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[DC1C2C3F7FA2E766]) []
o.a.s.SolrTestCaseJ4 ###Starting testBiDir
[junit4] 2> 764765 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[DC1C2C3F7FA2E766]) []
o.a.s.c.MiniSolrCloudCluster Starting cluster of 1 servers in
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.cdcr.CdcrBidirectionalTest_DC1C2C3F7FA2E766-001/cdcr-cluster2-001
[junit4] 2> 764765 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[DC1C2C3F7FA2E766]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 764766 INFO (Thread-2219) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 764766 INFO (Thread-2219) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 764767 ERROR (Thread-2219) [] o.a.z.s.ZooKeeperServer
ZKShutdownHandler is not registered, so ZooKeeper server won't take any action
on ERROR or SHUTDOWN server state changes
[junit4] 2> 764866 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[DC1C2C3F7FA2E766]) []
o.a.s.c.ZkTestServer start zk server on port:39799
[junit4] 2> 764867 INFO (zkConnectionManagerCallback-4849-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
[junit4] 2> 764875 INFO (jetty-launcher-4846-thread-1) []
o.e.j.s.Server jetty-9.4.11.v20180605; built: 2018-06-05T18:24:03.829Z; git:
d5fc0523cfa96bfebfbda19606cad384d772f04c; jvm 10.0.1+10
[junit4] 2> 764877 INFO (jetty-launcher-4846-thread-1) []
o.e.j.s.session DefaultSessionIdManager workerName=node0
[junit4] 2> 764877 INFO (jetty-launcher-4846-thread-1) []
o.e.j.s.session No SessionScavenger set, using defaults
[junit4] 2> 764877 INFO (jetty-launcher-4846-thread-1) []
o.e.j.s.session node0 Scavenging every 66ms
[junit4] 2> 764877 INFO (jetty-launcher-4846-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@2e64b0b2{/solr,null,AVAILABLE}
[junit4] 2> 764878 INFO (jetty-launcher-4846-thread-1) []
o.e.j.s.AbstractConnector Started ServerConnector@6f2c7f8c{SSL,[ssl,
http/1.1]}{127.0.0.1:41413}
[junit4] 2> 764878 INFO (jetty-launcher-4846-thread-1) []
o.e.j.s.Server Started @764898ms
[junit4] 2> 764878 INFO (jetty-launcher-4846-thread-1) []
o.a.s.c.s.e.JettySolrRunner Jetty properties:
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 22467 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22467/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseSerialGC 11 tests failed. FAILED: org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore.test Error Message: expected: but was: Stack Trace: java.lang.AssertionError: expected: but was: at __randomizedtesting.SeedInfo.seed([BC266A8BBC96BD8C:34725551126AD074]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:327) at org.apache.solr.cloud.api.collections.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:145) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED:
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1973 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1973/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 4 tests failed. FAILED: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir Error Message: Captured an uncaught exception in thread: Thread[id=483, name=cdcr-replicator-134-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=483, name=cdcr-replicator-134-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Caused by: java.lang.AssertionError: 1606201754590904320 != 1606201754589855744 at __randomizedtesting.SeedInfo.seed([59F4B75D8590D2BA]:0) at org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611) at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125) at org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir Error Message: Captured an uncaught exception in thread: Thread[id=555, name=cdcr-replicator-263-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=555, name=cdcr-replicator-263-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Caused by: java.lang.AssertionError: 1606201769097953280 != 1606201768982609920 at __randomizedtesting.SeedInfo.seed([59F4B75D8590D2BA]:0) at org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611) at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125) at org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir Error Message: Captured an uncaught exception in thread: Thread[id=31816, name=cdcr-replicator-11347-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=31816, name=cdcr-replicator-11347-thread-1, state=RUNNABLE, group=TGRP-CdcrBidirectionalTest] Caused by: java.lang.AssertionError: 1606199397932072960 != 1606199397324947456 at __randomizedtesting.SeedInfo.seed([59F4B75D8590D2BA]:0) at org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611) at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125) at org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild Error Message: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException Stack Trace: java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException at __randomizedtesting.SeedInfo.seed([59F4B75D8590D2BA:8679D5E2BBF987D8]:0) at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at
[JENKINS] Solr-reference-guide-master - Build # 8893 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-master/8893/ Log: Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer ERROR: websites1 is offline; cannot locate JDK 1.8 (latest) ERROR: websites1 is offline; cannot locate JDK 1.8 (latest) ERROR: Issue with creating launcher for agent websites1. The agent has not been fully initialized yet [EnvInject] - Loading node environment variables. ERROR: websites1 is offline; cannot locate JDK 1.8 (latest) ERROR: websites1 is offline; cannot locate JDK 1.8 (latest) ERROR: websites1 is offline; cannot locate JDK 1.8 (latest) Building remotely on websites1 (git-websites svn-websites)ERROR: websites1 seems to be offline ERROR: Step ‘Archive the artifacts’ failed: no workspace for Solr-reference-guide-master #8893 ERROR: Step ‘Publish Javadoc’ failed: no workspace for Solr-reference-guide-master #8893 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+22) - Build # 2334 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2334/ Java: 64bit/jdk-11-ea+22 -XX:+UseCompressedOops -XX:+UseG1GC 10 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.SchemaApiFailureTest Error Message: Stack Trace: java.util.concurrent.TimeoutException at __randomizedtesting.SeedInfo.seed([9F4482BEBE570DE2]:0) at org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1469) at org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:450) at org.apache.solr.schema.SchemaApiFailureTest.setupCluster(SchemaApiFailureTest.java:43) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName Error Message: Could not find collection:first_collection Stack Trace: java.lang.AssertionError: Could not find collection:first_collection at __randomizedtesting.SeedInfo.seed([9F4482BEBE570DE2:2CC0554E05069533]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:261) at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:231) at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:155) at org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName(TestMiniSolrCloudClusterSSL.java:137) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 747 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/747/ Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 7 tests failed. FAILED: org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive Error Message: Jetty Connector is not open: -2 Stack Trace: java.lang.IllegalStateException: Jetty Connector is not open: -2 at __randomizedtesting.SeedInfo.seed([54C5CA779D41A46:80F870D0452BA3DE]:0) at org.apache.solr.client.solrj.embedded.JettySolrRunner.getBaseUrl(JettySolrRunner.java:499) at org.apache.solr.cloud.MiniSolrCloudCluster.getReplicaJetty(MiniSolrCloudCluster.java:539) at org.apache.solr.cloud.LeaderTragicEventTest.corruptLeader(LeaderTragicEventTest.java:100) at org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive(LeaderTragicEventTest.java:150) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test Error Message: Error
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 98 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/98/ 10 tests failed. FAILED: org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive Error Message: Jetty Connector is not open: -2 Stack Trace: java.lang.IllegalStateException: Jetty Connector is not open: -2 at __randomizedtesting.SeedInfo.seed([4E5387D262B866C2:CBE7ABA55E47DF5A]:0) at org.apache.solr.client.solrj.embedded.JettySolrRunner.getBaseUrl(JettySolrRunner.java:499) at org.apache.solr.cloud.MiniSolrCloudCluster.getReplicaJetty(MiniSolrCloudCluster.java:539) at org.apache.solr.cloud.LeaderTragicEventTest.corruptLeader(LeaderTragicEventTest.java:100) at org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive(LeaderTragicEventTest.java:150) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test Error Message: Error from server at
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 22466 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22466/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger Error Message: expected:<3> but was:<2> Stack Trace: java.lang.AssertionError: expected:<3> but was:<2> at __randomizedtesting.SeedInfo.seed([9DFABB5FBF78257E:FE318DDD26B75653]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:112) at org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:65) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log:
[jira] [Commented] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[ https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545877#comment-16545877 ] Cao Manh Dat commented on SOLR-12412: - Sorry about the failure, I will take a look today. > Leader should give up leadership when IndexWriter.tragedy occur > --- > > Key: SOLR-12412 > URL: https://issues.apache.org/jira/browse/SOLR-12412 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-12412.patch, SOLR-12412.patch, > jenkins-failure-2325.log > > > When a leader meets some kind of unrecoverable exception (ie: > CorruptedIndexException). The shard will go into the readable state and human > has to intervene. In that case, it will be the best if the leader gives up > its leadership and let other replicas become the leader. -- 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
[jira] [Commented] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[
https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545876#comment-16545876
]
Varun Thacker commented on SOLR-12412:
--
With regards to the actual failure , I think we are shutting down the wrong
Jetty?
>From the seed we have numReplicas=2. Which means we want to shutdown the
>non-leader shard but from the logs it's shutting down the leader jetty?
And then when we go to corrupt the leader jetty , it's actually closed ?
{code:java}
[junit4] 2> 13526 INFO
(TEST-LeaderTragicEventTest.testOtherReplicasAreNotActive-seed#[7146D51E1F1D9F1A])
[ ] o.a.s.c.ZkController Remove node as live in
ZooKeeper:/live_nodes/127.0.0.1:35477_solr
[junit4] 2> 13526 INFO
(TEST-LeaderTragicEventTest.testOtherReplicasAreNotActive-seed#[7146D51E1F1D9F1A])
[ ] o.a.s.m.SolrMetricManager Closing metric reporters for
registry=solr.cluster, tag=null
[junit4] 2> 13526 INFO (zkCallback-17-thread-1) [ ] o.a.s.c.c.ZkStateReader
Updated live nodes from ZooKeeper... (2) -> (1)
[junit4] 2> 13543 INFO (coreCloseExecutor-33-thread-1) [n:127.0.0.1:35477_solr
c:collection1 s:shard1 r:core_node3 x:collection1_shard1_replica_n1]
o.a.s.m.SolrMetricManager Closing metric reporters for
registry=solr.collection.collection1.shard1.leader, tag=f37433
...
[junit4] 2> 13554 INFO
(OverseerStateUpdate-72132540686336006-127.0.0.1:35477_solr-n_00) [ ]
o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:35477_solr
[junit4] 2> 13554 WARN
(OverseerAutoScalingTriggerThread-72132540686336006-127.0.0.1:35477_solr-n_00)
[ ] o.a.s.c.a.OverseerTriggerThread OverseerTriggerThread woken up but we are
closed, exiting.
[junit4] 2> 13562 INFO (zkCallback-17-thread-1) [ ]
o.a.s.c.OverseerElectionContext I am going to be the leader 127.0.0.1:36827_solr
[junit4] 2> 13562 INFO (zkCallback-17-thread-1) [ ] o.a.s.c.Overseer Overseer
(id=72132540686336005-127.0.0.1:36827_solr-n_01) starting
...
[junit4] 2> 13575 INFO
(TEST-LeaderTragicEventTest.testOtherReplicasAreNotActive-seed#[7146D51E1F1D9F1A])
[ ] o.a.s.SolrTestCaseJ4 ###Ending testOtherReplicasAreNotActive
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=LeaderTragicEventTest
-Dtests.method=testOtherReplicasAreNotActive -Dtests.seed=7146D51E1F1D9F1A
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=es-CL -Dtests.timezone=Pacific/Niue -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 5.96s J2 | LeaderTragicEventTest.testOtherReplicasAreNotActive
<<<
[junit4] > Throwable #1: java.lang.IllegalStateException: Jetty Connector is
not open: -2
[junit4] > at
__randomizedtesting.SeedInfo.seed([7146D51E1F1D9F1A:F4F2F96923E22682]:0)
[junit4] > at
org.apache.solr.client.solrj.embedded.JettySolrRunner.getBaseUrl(JettySolrRunner.java:499)
[junit4] > at
org.apache.solr.cloud.MiniSolrCloudCluster.getReplicaJetty(MiniSolrCloudCluster.java:539)
[junit4] > at
org.apache.solr.cloud.LeaderTragicEventTest.corruptLeader(LeaderTragicEventTest.java:100)
[junit4] > at
org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive(LeaderTragicEventTest.java:150)
[junit4] > at java.lang.Thread.run(Thread.java:748){code}
> Leader should give up leadership when IndexWriter.tragedy occur
> ---
>
> Key: SOLR-12412
> URL: https://issues.apache.org/jira/browse/SOLR-12412
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12412.patch, SOLR-12412.patch,
> jenkins-failure-2325.log
>
>
> When a leader meets some kind of unrecoverable exception (ie:
> CorruptedIndexException). The shard will go into the readable state and human
> has to intervene. In that case, it will be the best if the leader gives up
> its leadership and let other replicas become the leader.
--
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
[jira] [Commented] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[
https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545867#comment-16545867
]
Varun Thacker commented on SOLR-12412:
--
This test class has two methods
* test()
* testOtherReplicasAreNotActive()
Both try creating a collection "collection1" . We should probably put the
delete collection in a finally block. This would avoid the following error
{code:java}
[junit4] 2> 13586 INFO
(TEST-LeaderTragicEventTest.test-seed#[7146D51E1F1D9F1A]) [ ]
o.a.s.SolrTestCaseJ4 ###Starting test
[junit4] 2> 13588 INFO (qtp1687913357-34) [n:127.0.0.1:36827_solr ]
o.a.s.h.a.CollectionsHandler Invoked Collection Action :create with params
collection.configName=config=collection1=2=CREATE=1=javabin=2
and sendToOCPQueue=true
[junit4] 2> 13590 INFO (OverseerThreadFactory-38-thread-1) [ ]
o.a.s.c.a.c.CreateCollectionCmd Create collection collection1
[junit4] 2> 13591 ERROR (OverseerThreadFactory-38-thread-1) [ ]
o.a.s.c.a.c.OverseerCollectionMessageHandler Collection: collection1 operation:
create failed:org.apache.solr.common.SolrException: collection already exists:
collection1
[junit4] 2> at
org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:106)
[junit4] 2> at
org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:255)
[junit4] 2> at
org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:469)
[junit4] 2> at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[junit4] 2> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit4] 2> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit4] 2> at java.lang.Thread.run(Thread.java:748){code}
Since testOtherReplicasAreNotActive() failed with an error , it didn't delete
the collection1. test() was run after that and hit the above error. test()
still passed even if the create collection failed ( which means there was
already a corrupted index ) . Sounds fishy?
We could replace this the following line?
{code:java}
- int numReplicas = random().nextInt(2) + 1;
+ int numReplicas = TestUtil.nextInt(random(), 1, 2);{code}
testOtherReplicasAreNotActive() -> When there are two replicas , where are we
actually checking if it becomes active or not after it has been started again?
i.e after this statement should we be checking if it becomes active and fail
the test?
{code:java}
if (otherReplicaJetty != null) {
// won't be able to do anything here, since this replica can't recovery from
the leader
otherReplicaJetty.start();
}{code}
testOtherReplicasAreNotActive() -> when the test selects one replica , what
are we testing exactly ? From what I can understand we are corrupting the
leader of a single sharded collection and then validating if it's still the
leader ?
I'm trying to understand the corruptLeader() method : Why are we trying to
delete segment files after every add ? What if we just add the 100 docs and
then delete the segments_N file ?
Happy to pitch in just wanted to understand the test better before diving in
> Leader should give up leadership when IndexWriter.tragedy occur
> ---
>
> Key: SOLR-12412
> URL: https://issues.apache.org/jira/browse/SOLR-12412
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12412.patch, SOLR-12412.patch,
> jenkins-failure-2325.log
>
>
> When a leader meets some kind of unrecoverable exception (ie:
> CorruptedIndexException). The shard will go into the readable state and human
> has to intervene. In that case, it will be the best if the leader gives up
> its leadership and let other replicas become the leader.
--
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
[jira] [Commented] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[ https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545831#comment-16545831 ] Hoss Man commented on SOLR-12412: - Dat: in the past 7 days, LeaderTragicEventTest.testOtherReplicasAreNotActive has failed 36.33% (222 / 611) of all jenkins runs, and LeaderTragicEventTest.test has failed 21.28% (130 / 611). In just the past 24 hours, we've seen a failure rate of 29.09% (16 / 55) for both methods. It seems that even after your most recent commit, these tests need significant hardening to run even remotely close to reliably? > Leader should give up leadership when IndexWriter.tragedy occur > --- > > Key: SOLR-12412 > URL: https://issues.apache.org/jira/browse/SOLR-12412 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-12412.patch, SOLR-12412.patch, > jenkins-failure-2325.log > > > When a leader meets some kind of unrecoverable exception (ie: > CorruptedIndexException). The shard will go into the readable state and human > has to intervene. In that case, it will be the best if the leader gives up > its leadership and let other replicas become the leader. -- 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
[jira] [Commented] (LUCENE-8263) Add indexPctDeletedTarget as a parameter to TieredMergePolicy to control more aggressive merging
[ https://issues.apache.org/jira/browse/LUCENE-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545829#comment-16545829 ] Erick Erickson commented on LUCENE-8263: bq. ...is that if enough segments somehow end up having a delete % above forceMergeDeletesPctAllowed Right, the cap is always 2x the index size, and if you don't have that much free space you'll be courting disaster sometime. forceMerge has something akin to what you're looking for, but forceMergeDeletes doesn't. That's been mentioned as a possible enhancement. Although if you don't have at least as much free disk as your index takes up you're courting trouble down the road anyway. > Add indexPctDeletedTarget as a parameter to TieredMergePolicy to control more > aggressive merging > > > Key: LUCENE-8263 > URL: https://issues.apache.org/jira/browse/LUCENE-8263 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: LUCENE-8263.patch > > > Spinoff of LUCENE-7976 to keep the two issues separate. > The current TMP allows up to 50% deleted docs, which can be wasteful on large > indexes. This parameter will do more aggressive merging of segments with > deleted documents when the _total_ percentage of deleted docs in the entire > index exceeds it. > Setting this to 50% should approximate current behavior. Setting it to 20% > caused the first cut at this to increase I/O roughly 10%. Setting it to 10% > caused about a 50% increase in I/O. > I was conflating the two issues, so I'll change 7976 and comment out the bits > that reference this new parameter. After it's checked in we can bring this > back. That should be less work than reconstructing this later. > Among the questions to be answered: > 1> what should the default be? I propose 20% as it results in significantly > less space wasted and helps control heap usage for a modest increase in I/O. > 2> what should the floor be? I propose 10% with _strong_ documentation > warnings about not setting it below 20%. > 3> should there be two parameters? I think this was discussed somewhat in > 7976. The first cut at this used this number for two purposes: > 3a> the total percentage of deleted docs index-wide to trip this trigger > 3b> the percentage of an _individual_ segment that had to be deleted if the > segment was over maxSegmentSize/2 bytes in order to be eligible for merging. > Empirically, using the same percentage for both caused the merging to hover > around the value specified for this parameter. > My proposal for <3> would be to have the parameter do double-duty. Assuming > my preliminary results hold, you specify this parameter at, say, 20% and once > the index hits that % deleted docs it hovers right around there, even if > you've forceMerged earlier down to 1 segment. This seems in line with what > I'd expect and adding another parameter seems excessively complicated to no > good purpose. We could always add something like that later if we wanted. -- 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
[jira] [Updated] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[ https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-12412: - Attachment: jenkins-failure-2325.log > Leader should give up leadership when IndexWriter.tragedy occur > --- > > Key: SOLR-12412 > URL: https://issues.apache.org/jira/browse/SOLR-12412 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-12412.patch, SOLR-12412.patch, > jenkins-failure-2325.log > > > When a leader meets some kind of unrecoverable exception (ie: > CorruptedIndexException). The shard will go into the readable state and human > has to intervene. In that case, it will be the best if the leader gives up > its leadership and let other replicas become the leader. -- 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
[jira] [Commented] (SOLR-12412) Leader should give up leadership when IndexWriter.tragedy occur
[ https://issues.apache.org/jira/browse/SOLR-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545823#comment-16545823 ] Varun Thacker commented on SOLR-12412: -- Jenkins is reporting quite a few failures for this test. I'm attaching one such run. I ran the seed a couple of times locally but was not able to reproduce it , so it's timing related most likely. > Leader should give up leadership when IndexWriter.tragedy occur > --- > > Key: SOLR-12412 > URL: https://issues.apache.org/jira/browse/SOLR-12412 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat >Priority: Major > Attachments: SOLR-12412.patch, SOLR-12412.patch, > jenkins-failure-2325.log > > > When a leader meets some kind of unrecoverable exception (ie: > CorruptedIndexException). The shard will go into the readable state and human > has to intervene. In that case, it will be the best if the leader gives up > its leadership and let other replicas become the leader. -- 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
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_172) - Build # 2333 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2333/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive Error Message: Jetty Connector is not open: -2 Stack Trace: java.lang.IllegalStateException: Jetty Connector is not open: -2 at __randomizedtesting.SeedInfo.seed([58E02E272807B982:DD54025014F8001A]:0) at org.apache.solr.client.solrj.embedded.JettySolrRunner.getBaseUrl(JettySolrRunner.java:499) at org.apache.solr.cloud.MiniSolrCloudCluster.getReplicaJetty(MiniSolrCloudCluster.java:539) at org.apache.solr.cloud.LeaderTragicEventTest.corruptLeader(LeaderTragicEventTest.java:100) at org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive(LeaderTragicEventTest.java:150) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test
[jira] [Commented] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
[
https://issues.apache.org/jira/browse/LUCENE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545795#comment-16545795
]
Hoss Man commented on LUCENE-8403:
--
{quote}Is this valuable to the wider community? Is there a way we can design
this to not break CheckIndex's contract while at the same time lessening
storage for unneeded tokens?
{quote}
Half assed straw man suggestion from the peanut gallery: would it make sense to
enhance the TermVector codec API in some way that would allow CheckIndex to ask
the codec which terms (from the posting list) to expect?
> Support 'filtered' term vectors - don't require all terms to be present
> ---
>
> Key: LUCENE-8403
> URL: https://issues.apache.org/jira/browse/LUCENE-8403
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael Braun
>Priority: Minor
>
> The genesis of this was a conversation and idea from [~dsmiley] several years
> ago.
> In order to optimize term vector storage, we may not actually need all tokens
> to be present in the term vectors - and if so, ideally our codec could just
> opt not to store them.
> I attempted to fork the standard codec and override the TermVectorsFormat and
> TermVectorsWriter to ignore storing certain Terms within a field. This
> worked, however, CheckIndex checks that the terms present in the standard
> postings are also present in the TVs, if TVs enabled. So this then doesn't
> work as 'valid' according to CheckIndex.
> Can the TermVectorsFormat be made in such a way to support configuration of
> tokens that should not be stored (benefits: less storage, more optimal
> retrieval per doc)? Is this valuable to the wider community? Is there a way
> we can design this to not break CheckIndex's contract while at the same time
> lessening storage for unneeded tokens?
--
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
[jira] [Comment Edited] (LUCENE-8263) Add indexPctDeletedTarget as a parameter to TieredMergePolicy to control more aggressive merging
[
https://issues.apache.org/jira/browse/LUCENE-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545788#comment-16545788
]
Marc Morissette edited comment on LUCENE-8263 at 7/16/18 10:02 PM:
---
{quote}I've gone back and forth on this. Now that optimize and forceMerge
respect maxSegmentSize I've been thinking that those operations would suffice
for those real-world edge cases.
forceMergeDeletes (expungeDeletes) has a maximum percent of deletes allowed per
segment for instance that must be between 0 and 100. 0 is roughly equivalent to
forceMerge/optimize at this point. And will not create any segments over
maxSegmentSizeMB.
{quote}
I hadn't considered using forceMergeDeletes to address these edge cases but the
more I think about it, the more I like it. Consider me convinced.
My only remaining concern with forceMergeDeletes as it is currently designed
(and if I'm reading the code correctly) is that if enough segments somehow end
up having a delete % above forceMergeDeletesPctAllowed, then it is possible for
it to use a lot of disk space. Perhaps we could find a way to configure an
upper limit on the number of merges that forceMergeDeletes can perform per
call? When configured this way, each forceMergeDeletes could only claim a
maximum amount of disk space before returning. Repeated calls would be
necessary to "clean" an entire index but if each one were accompanied by a soft
commit, then the amount of free disk space required to perform the entire
operation would be more predictable.
was (Author: marc.morissette):
{quote}I've gone back and forth on this. Now that optimize and forceMerge
respect maxSegmentSize I've been thinking that those operations would suffice
for those real-world edge cases.
forceMergeDeletes (expungeDeletes) has a maximum percent of deletes allowed per
segment for instance that must be between 0 and 100. 0 is roughly equivalent to
forceMerge/optimize at this point. And will not create any segments over
maxSegmentSizeMB.
{quote}
I hadn't considered using forceMergeDeletes to address these edge cases but the
more I think about it, the more I like it. Consider me convinced.
My only remaining concern with forceMergeDeletes as it is currently designed
(and if I'm reading the code correctly) is that if enough segments somehow end
up having a delete % above forceMergeDeletesPctAllowed, then it is possible for
it to use a lot of disk space. Perhaps we could find a way to configure an
upper limit on the number of merges that forceMergeDeletes can perform per
call? When configured this way, each forceMergeDeletes could only claim a
maximum amount of disk space before returning. Repeated calls would be
necessary to "clean" an entire index but if each one were accompanied by a soft
commit, then the amount of free disk space required to perform the operation
would be more predictable.
> Add indexPctDeletedTarget as a parameter to TieredMergePolicy to control more
> aggressive merging
>
>
> Key: LUCENE-8263
> URL: https://issues.apache.org/jira/browse/LUCENE-8263
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-8263.patch
>
>
> Spinoff of LUCENE-7976 to keep the two issues separate.
> The current TMP allows up to 50% deleted docs, which can be wasteful on large
> indexes. This parameter will do more aggressive merging of segments with
> deleted documents when the _total_ percentage of deleted docs in the entire
> index exceeds it.
> Setting this to 50% should approximate current behavior. Setting it to 20%
> caused the first cut at this to increase I/O roughly 10%. Setting it to 10%
> caused about a 50% increase in I/O.
> I was conflating the two issues, so I'll change 7976 and comment out the bits
> that reference this new parameter. After it's checked in we can bring this
> back. That should be less work than reconstructing this later.
> Among the questions to be answered:
> 1> what should the default be? I propose 20% as it results in significantly
> less space wasted and helps control heap usage for a modest increase in I/O.
> 2> what should the floor be? I propose 10% with _strong_ documentation
> warnings about not setting it below 20%.
> 3> should there be two parameters? I think this was discussed somewhat in
> 7976. The first cut at this used this number for two purposes:
> 3a> the total percentage of deleted docs index-wide to trip this trigger
> 3b> the percentage of an _individual_ segment that had to be deleted if the
> segment was over maxSegmentSize/2 bytes in order to be eligible for merging.
> Empirically, using the same percentage for both caused the
[jira] [Commented] (LUCENE-8263) Add indexPctDeletedTarget as a parameter to TieredMergePolicy to control more aggressive merging
[
https://issues.apache.org/jira/browse/LUCENE-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545788#comment-16545788
]
Marc Morissette commented on LUCENE-8263:
-
{quote}I've gone back and forth on this. Now that optimize and forceMerge
respect maxSegmentSize I've been thinking that those operations would suffice
for those real-world edge cases.
forceMergeDeletes (expungeDeletes) has a maximum percent of deletes allowed per
segment for instance that must be between 0 and 100. 0 is roughly equivalent to
forceMerge/optimize at this point. And will not create any segments over
maxSegmentSizeMB.
{quote}
I hadn't considered using forceMergeDeletes to address these edge cases but the
more I think about it, the more I like it. Consider me convinced.
My only remaining concern with forceMergeDeletes as it is currently designed
(and if I'm reading the code correctly) is that if enough segments somehow end
up having a delete % above forceMergeDeletesPctAllowed, then it is possible for
it to use a lot of disk space. Perhaps we could find a way to configure an
upper limit on the number of merges that forceMergeDeletes can perform per
call? When configured this way, each forceMergeDeletes could only claim a
maximum amount of disk space before returning. Repeated calls would be
necessary to "clean" an entire index but if each one were accompanied by a soft
commit, then the amount of free disk space required to perform the operation
would be more predictable.
> Add indexPctDeletedTarget as a parameter to TieredMergePolicy to control more
> aggressive merging
>
>
> Key: LUCENE-8263
> URL: https://issues.apache.org/jira/browse/LUCENE-8263
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-8263.patch
>
>
> Spinoff of LUCENE-7976 to keep the two issues separate.
> The current TMP allows up to 50% deleted docs, which can be wasteful on large
> indexes. This parameter will do more aggressive merging of segments with
> deleted documents when the _total_ percentage of deleted docs in the entire
> index exceeds it.
> Setting this to 50% should approximate current behavior. Setting it to 20%
> caused the first cut at this to increase I/O roughly 10%. Setting it to 10%
> caused about a 50% increase in I/O.
> I was conflating the two issues, so I'll change 7976 and comment out the bits
> that reference this new parameter. After it's checked in we can bring this
> back. That should be less work than reconstructing this later.
> Among the questions to be answered:
> 1> what should the default be? I propose 20% as it results in significantly
> less space wasted and helps control heap usage for a modest increase in I/O.
> 2> what should the floor be? I propose 10% with _strong_ documentation
> warnings about not setting it below 20%.
> 3> should there be two parameters? I think this was discussed somewhat in
> 7976. The first cut at this used this number for two purposes:
> 3a> the total percentage of deleted docs index-wide to trip this trigger
> 3b> the percentage of an _individual_ segment that had to be deleted if the
> segment was over maxSegmentSize/2 bytes in order to be eligible for merging.
> Empirically, using the same percentage for both caused the merging to hover
> around the value specified for this parameter.
> My proposal for <3> would be to have the parameter do double-duty. Assuming
> my preliminary results hold, you specify this parameter at, say, 20% and once
> the index hits that % deleted docs it hovers right around there, even if
> you've forceMerged earlier down to 1 segment. This seems in line with what
> I'd expect and adding another parameter seems excessively complicated to no
> good purpose. We could always add something like that later if we wanted.
--
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
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10) - Build # 22465 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22465/ Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive Error Message: Jetty Connector is not open: -2 Stack Trace: java.lang.IllegalStateException: Jetty Connector is not open: -2 at __randomizedtesting.SeedInfo.seed([C4143C4A20E63068:41A0103D1C1989F0]:0) at org.apache.solr.client.solrj.embedded.JettySolrRunner.getBaseUrl(JettySolrRunner.java:499) at org.apache.solr.cloud.MiniSolrCloudCluster.getReplicaJetty(MiniSolrCloudCluster.java:539) at org.apache.solr.cloud.LeaderTragicEventTest.corruptLeader(LeaderTragicEventTest.java:100) at org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive(LeaderTragicEventTest.java:150) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test Error Message: Error
[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_172) - Build # 694 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/694/ Java: 32bit/jdk1.8.0_172 -client -XX:+UseG1GC 11 tests failed. FAILED: org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testChildDoctransformer Error Message: Doc count does not match expected:<10205> but was:<10204> Stack Trace: java.lang.AssertionError: Doc count does not match expected:<10205> but was:<10204> at __randomizedtesting.SeedInfo.seed([8C84A5D22BAB603E:FF5EBA48A7B31738]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.client.solrj.SolrExampleTests.testChildDoctransformer(SolrExampleTests.java:1797) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.JDBCStreamTest Error
Is this code redundant?
While poking around trying to understand how to get docValues from the Solr level I ran across these two methods, both static DocStreamer.convertLuceneDocToSolrDoc RealTimeGetCompnent.toSolrDoc They look very similar, should I raise a JIRA about removing one of them? Which one? The one in RealTimeGet is only used in RealTimeGet so that'd be my candidate. I see some minor differences, does anyone know whether they're important? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8401) Add PassageBuilder to help construct highlights using MatchesIterator
[ https://issues.apache.org/jira/browse/LUCENE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545682#comment-16545682 ] David Smiley commented on LUCENE-8401: -- Along the idea of reusable components, adding a PassageFormatter would be good too. You could take the one from the UH. I enhanced it a little in the PR for LUCENE-8286. A reusable PassageScorer may be problematic until some time or might not ever bee if it's too highlighter specific. The UH could be changed in 8.0 to use the new common components. > Add PassageBuilder to help construct highlights using MatchesIterator > - > > Key: LUCENE-8401 > URL: https://issues.apache.org/jira/browse/LUCENE-8401 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/highlighter >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8401.patch > > > Jim and I discussed a while back the idea of adding highlighter components, > rather than a fully-fledged highlighter, which would allow users to build > their own specialised highlighters. To that end, I'd like to add a > PassageBuilder class that uses the Matches API to break text up into passages > containing hits. -- 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
[jira] [Commented] (LUCENE-8401) Add PassageBuilder to help construct highlights using MatchesIterator
[ https://issues.apache.org/jira/browse/LUCENE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545661#comment-16545661 ] David Smiley commented on LUCENE-8401: -- This is a fine idea Alan. I especially like the peeking iterator idea. * Should there be a new "o.a.l.highlighter.common" package for these components? * typo: "continaing", "Definnes" * Maybe PassageBuilder's lifecycle would be simpler if you simply re-create it for each "text" value? Then it would quite simply be an Iterator. Well nevermind; there's the IOException and reuse of the Peeking thing. * make Hit members protected and/or add getters. Someone might want to add other interesting metadata. * In Passage's Constructor, compare the end offset if start offset is equal. (Comparator.thenComparing makes this easy). I ran into this ambiguity while working on LUCENE-8286. Maybe Hit should implement Comparable? > Add PassageBuilder to help construct highlights using MatchesIterator > - > > Key: LUCENE-8401 > URL: https://issues.apache.org/jira/browse/LUCENE-8401 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/highlighter >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8401.patch > > > Jim and I discussed a while back the idea of adding highlighter components, > rather than a fully-fledged highlighter, which would allow users to build > their own specialised highlighters. To that end, I'd like to add a > PassageBuilder class that uses the Matches API to break text up into passages > containing hits. -- 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
[jira] [Updated] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8402:
--
Component/s: core/other
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
> Components: core/other
>Reporter: Jim Ferenczi
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Updated] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-8402:
--
Fix Version/s: 7.5
master (8.0)
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545642#comment-16545642
]
Uwe Schindler commented on LUCENE-8402:
---
Sorry for this. I did not fail in my test, maybe because of randomness.
There are other test that do this ([~mbraun688] added the SuppressWarnings for
the other tests). But this is bogus anyways: Especially it contains an
assertion that the identityHashCode of 2 different objects needs to be
different, which is no requirement by the spec. It can be equal, too - so on
the long term the test could have failed also before!!!
+1 to remove the identity/equals crazyness. We should also review the other
tests that were SuppressWarning'd because of this!
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
[ https://issues.apache.org/jira/browse/LUCENE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545638#comment-16545638 ] Michael Braun commented on LUCENE-8403: --- Yes correct [~dsmiley], the CheckIndexes were hit as a result. So in practice this forked codec works for us, but testing breaks. > Support 'filtered' term vectors - don't require all terms to be present > --- > > Key: LUCENE-8403 > URL: https://issues.apache.org/jira/browse/LUCENE-8403 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > The genesis of this was a conversation and idea from [~dsmiley] several years > ago. > In order to optimize term vector storage, we may not actually need all tokens > to be present in the term vectors - and if so, ideally our codec could just > opt not to store them. > I attempted to fork the standard codec and override the TermVectorsFormat and > TermVectorsWriter to ignore storing certain Terms within a field. This > worked, however, CheckIndex checks that the terms present in the standard > postings are also present in the TVs, if TVs enabled. So this then doesn't > work as 'valid' according to CheckIndex. > Can the TermVectorsFormat be made in such a way to support configuration of > tokens that should not be stored (benefits: less storage, more optimal > retrieval per doc)? Is this valuable to the wider community? Is there a way > we can design this to not break CheckIndex's contract while at the same time > lessening storage for unneeded tokens? -- 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
[jira] [Comment Edited] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545634#comment-16545634
]
Jim Ferenczi edited comment on LUCENE-8402 at 7/16/18 7:09 PM:
---
Since it is a deprecated function I don't think we should put it back, [~markh]
can you explain the intent of forbidding the reuse of Integers in this test ?
It doesn't seem to be required.
was (Author: jim.ferenczi):
Since it is a deprecated function I don't think we should put it back, [~markh]
can you explain the intent of forbidding the reuse of Integers in this test. It
doesn't seem to be required.
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545634#comment-16545634
]
Jim Ferenczi commented on LUCENE-8402:
--
Since it is a deprecated function I don't think we should put it back, [~markh]
can you explain the intent of forbidding the reuse of Integers in this test. It
doesn't seem to be required.
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
[ https://issues.apache.org/jira/browse/LUCENE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545612#comment-16545612 ] Robert Muir commented on LUCENE-8403: - every index created by tests gets run by checkindex. No, I don't think its ok to make checkindex wimpy, for any reason... > Support 'filtered' term vectors - don't require all terms to be present > --- > > Key: LUCENE-8403 > URL: https://issues.apache.org/jira/browse/LUCENE-8403 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > The genesis of this was a conversation and idea from [~dsmiley] several years > ago. > In order to optimize term vector storage, we may not actually need all tokens > to be present in the term vectors - and if so, ideally our codec could just > opt not to store them. > I attempted to fork the standard codec and override the TermVectorsFormat and > TermVectorsWriter to ignore storing certain Terms within a field. This > worked, however, CheckIndex checks that the terms present in the standard > postings are also present in the TVs, if TVs enabled. So this then doesn't > work as 'valid' according to CheckIndex. > Can the TermVectorsFormat be made in such a way to support configuration of > tokens that should not be stored (benefits: less storage, more optimal > retrieval per doc)? Is this valuable to the wider community? Is there a way > we can design this to not break CheckIndex's contract while at the same time > lessening storage for unneeded tokens? -- 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
[jira] [Commented] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
[ https://issues.apache.org/jira/browse/LUCENE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545609#comment-16545609 ] David Smiley commented on LUCENE-8403: -- Ah, I remember this. Here, the TVs are only in use for the UnifiedHighlighter for MultiTermQueries, and we had some interesting analysis in which we can know categorically that some terms will never be matched by our MTQs, and so they are dead weight. Possible 40-50% dead weight for the app in question, if I recall. Is it a real problem that CheckIndex complains? I suppose that might come up in tests via the lucene-test-framework randomization that occasionally calls CheckIndex? I can't seem to find those call-sites right now though. CC [~rcmuir] > Support 'filtered' term vectors - don't require all terms to be present > --- > > Key: LUCENE-8403 > URL: https://issues.apache.org/jira/browse/LUCENE-8403 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Priority: Minor > > The genesis of this was a conversation and idea from [~dsmiley] several years > ago. > In order to optimize term vector storage, we may not actually need all tokens > to be present in the term vectors - and if so, ideally our codec could just > opt not to store them. > I attempted to fork the standard codec and override the TermVectorsFormat and > TermVectorsWriter to ignore storing certain Terms within a field. This > worked, however, CheckIndex checks that the terms present in the standard > postings are also present in the TVs, if TVs enabled. So this then doesn't > work as 'valid' according to CheckIndex. > Can the TermVectorsFormat be made in such a way to support configuration of > tokens that should not be stored (benefits: less storage, more optimal > retrieval per doc)? Is this valuable to the wider community? Is there a way > we can design this to not break CheckIndex's contract while at the same time > lessening storage for unneeded tokens? -- 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
[jira] [Created] (SOLR-12556) JSON Field Facet refinement can return incorrect counts/stats for sorted buckets -- when using processEmpty
Hoss Man created SOLR-12556:
---
Summary: JSON Field Facet refinement can return incorrect
counts/stats for sorted buckets -- when using processEmpty
Key: SOLR-12556
URL: https://issues.apache.org/jira/browse/SOLR-12556
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Creating this spin off of SOLR-12343 - the fix in that issue addresses the most
common cases, but does not help when {{processEmpty:true}} is used...
{panel}
in {{getRefinement()}} you've got {{returnedAllBuckets}} taking into
consideration {{processEmpty:true}} - so that even if a shardA doesn't say it
has {{more:true}} we will still send it candidate bucketX for refinement if we
didn't explicitly {{saw}} bucketX on shardA. so far so good.
but then, once all the refinement is done, and we have a fully refined bucketX
it might now sort "lower" then an incomplete bucketY ... and
{{isBucketComplete}} doesn't pay any attention to {{processEmpty:true}} ... so
it sees that shardA does *not* have {{more:true}} and thinks (the incomplete)
bucketY is ok to return.
{panel}
--
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
[jira] [Commented] (SOLR-12343) JSON Field Facet refinement can return incorrect counts/stats for sorted buckets
[
https://issues.apache.org/jira/browse/SOLR-12343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545604#comment-16545604
]
Hoss Man commented on SOLR-12343:
-
{quote}but then, once all the refinement is done, and we have a fully refined
bucketX it might now sort "lower" then an incomplete bucketY ... and
{{isBucketComplete}} doesn't pay any attention to {{processEmpty:true}} ... so
it sees that shardA does *not* have {{more:true}} and thinks (the incomplete)
bucketY is ok to return.
{quote}
I haven't been able to come up with a better solution for this, and since
processEmpty is pretty special case, I think i'm just going to break it out
into it's own Jira, and revise the patch so that the current assertion failures
are confined to test methods that are \@AwaitsFix'ed on that issue -- that way
we can move forward with the existing fix that likely impacts more people.
> JSON Field Facet refinement can return incorrect counts/stats for sorted
> buckets
>
>
> Key: SOLR-12343
> URL: https://issues.apache.org/jira/browse/SOLR-12343
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Major
> Attachments: SOLR-12343.patch, SOLR-12343.patch, SOLR-12343.patch,
> SOLR-12343.patch, SOLR-12343.patch, SOLR-12343.patch, SOLR-12343.patch,
> __incomplete_processEmpty_microfix.patch
>
>
> The way JSON Facet's simple refinement "re-sorts" buckets after refinement
> can cause _refined_ buckets to be "bumped out" of the topN based on the
> refined counts/stats depending on the sort - causing _unrefined_ buckets
> originally discounted in phase#2 to bubble up into the topN and be returned
> to clients *with inaccurate counts/stats*
> The simplest way to demonstrate this bug (in some data sets) is with a
> {{sort: 'count asc'}} facet:
> * assume shard1 returns termX & termY in phase#1 because they have very low
> shard1 counts
> ** but *not* returned at all by shard2, because these terms both have very
> high shard2 counts.
> * Assume termX has a slightly lower shard1 count then termY, such that:
> ** termX "makes the cut" off for the limit=N topN buckets
> ** termY does not make the cut, and is the "N+1" known bucket at the end of
> phase#1
> * termX then gets included in the phase#2 refinement request against shard2
> ** termX now has a much higher _known_ total count then termY
> ** the coordinator now sorts termX "worse" in the sorted list of buckets
> then termY
> ** which causes termY to bubble up into the topN
> * termY is ultimately included in the final result _with incomplete
> count/stat/sub-facet data_ instead of termX
> ** this is all indepenent of the possibility that termY may actually have a
> significantly higher total count then termX across the entire collection
> ** the key problem is that all/most of the other terms returned to the
> client have counts/stats that are the cumulation of all shards, but termY
> only has the contributions from shard1
> Important Notes:
> * This scenerio can happen regardless of the amount of overrequest used.
> Additional overrequest just increases the number of "extra" terms needed in
> the index with "better" sort values then termX & termY in shard2
> * {{sort: 'count asc'}} is not just an exceptional/pathelogical case:
> ** any function sort where additional data provided shards during refinement
> can cause a bucket to "sort worse" can also cause this problem.
> ** Examples: {{sum(price_i) asc}} , {{min(price_i) desc}} , {{avg(price_i)
> asc|desc}} , etc...
--
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
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-11-ea+22) - Build # 7421 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7421/ Java: 64bit/jdk-11-ea+22 -XX:-UseCompressedOops -XX:+UseG1GC 46 tests failed. FAILED: org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive Error Message: Jetty Connector is not open: -2 Stack Trace: java.lang.IllegalStateException: Jetty Connector is not open: -2 at __randomizedtesting.SeedInfo.seed([D4F01947A5ADC7F1:5144353099527E69]:0) at org.apache.solr.client.solrj.embedded.JettySolrRunner.getBaseUrl(JettySolrRunner.java:499) at org.apache.solr.cloud.MiniSolrCloudCluster.getReplicaJetty(MiniSolrCloudCluster.java:539) at org.apache.solr.cloud.LeaderTragicEventTest.corruptLeader(LeaderTragicEventTest.java:100) at org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive(LeaderTragicEventTest.java:150) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test Error Message:
[jira] [Created] (LUCENE-8403) Support 'filtered' term vectors - don't require all terms to be present
Michael Braun created LUCENE-8403: - Summary: Support 'filtered' term vectors - don't require all terms to be present Key: LUCENE-8403 URL: https://issues.apache.org/jira/browse/LUCENE-8403 Project: Lucene - Core Issue Type: Improvement Reporter: Michael Braun The genesis of this was a conversation and idea from [~dsmiley] several years ago. In order to optimize term vector storage, we may not actually need all tokens to be present in the term vectors - and if so, ideally our codec could just opt not to store them. I attempted to fork the standard codec and override the TermVectorsFormat and TermVectorsWriter to ignore storing certain Terms within a field. This worked, however, CheckIndex checks that the terms present in the standard postings are also present in the TVs, if TVs enabled. So this then doesn't work as 'valid' according to CheckIndex. Can the TermVectorsFormat be made in such a way to support configuration of tokens that should not be stored (benefits: less storage, more optimal retrieval per doc)? Is this valuable to the wider community? Is there a way we can design this to not break CheckIndex's contract while at the same time lessening storage for unneeded tokens? -- 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
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 22464 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22464/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive Error Message: Jetty Connector is not open: -2 Stack Trace: java.lang.IllegalStateException: Jetty Connector is not open: -2 at __randomizedtesting.SeedInfo.seed([FB92C4C10B3FFDB6:7E26E8B637C0442E]:0) at org.apache.solr.client.solrj.embedded.JettySolrRunner.getBaseUrl(JettySolrRunner.java:499) at org.apache.solr.cloud.MiniSolrCloudCluster.getReplicaJetty(MiniSolrCloudCluster.java:539) at org.apache.solr.cloud.LeaderTragicEventTest.corruptLeader(LeaderTragicEventTest.java:100) at org.apache.solr.cloud.LeaderTragicEventTest.testOtherReplicasAreNotActive(LeaderTragicEventTest.java:150) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.LeaderTragicEventTest.test Error
[jira] [Commented] (SOLR-12541) Metrics handler throws an error if there are transient cores
[
https://issues.apache.org/jira/browse/SOLR-12541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545513#comment-16545513
]
Erick Erickson commented on SOLR-12541:
---
Blockers are reserved for issues that will hold up a release of Solr. Metrics
development was focused on SolrCloud and transient cores were never really
considered. Therefore I'm changing the priority. That would probably be a good
enhancement if you (or anyone else) can come up with a solution that would be a
good thing.
> Metrics handler throws an error if there are transient cores
>
>
> Key: SOLR-12541
> URL: https://issues.apache.org/jira/browse/SOLR-12541
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 7.2.1
>Reporter: Nandakishore Krishna
>Priority: Major
>
> My environment is as follows
> * Solr 7.2.1 in standalone mode.
> * 32GB heap
> * 150 cores with data getting continuously ingested to ~10 cores and all of
> the cores queried.
> * transient cache size is set to 30.
> The solr.xml is as follows
> {code:xml}
>
>
> 32
> true
> ${configSetBaseDir:configsets}
> class="HttpShardHandlerFactory">
> ${socketTimeout:60}
> ${connTimeout:6}
>
>
> {code}
> I get the following error when I request for "/solr/admin/metrics".
> {code}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 31
> },
> "error": {
> "msg": "Already closed",
> "trace": "org.apache.lucene.store.AlreadyClosedException: Already
> closed\n\tat
> org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:337)\n\tat
> org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:351)\n\tat
> org.apache.solr.core.SolrCore.getIndexDir(SolrCore.java:330)\n\tat
> org.apache.solr.handler.ReplicationHandler.lambda$initializeMetrics$5(ReplicationHandler.java:849)\n\tat
>
> org.apache.solr.util.stats.MetricUtils.convertGauge(MetricUtils.java:488)\n\tat
>
> org.apache.solr.util.stats.MetricUtils.convertMetric(MetricUtils.java:274)\n\tat
>
> org.apache.solr.util.stats.MetricUtils.lambda$toMaps$4(MetricUtils.java:213)\n\tat
>
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)\n\tat
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)\n\tat
>
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)\n\tat
> java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)\n\tat
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)\n\tat
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)\n\tat
>
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)\n\tat
>
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)\n\tat
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)\n\tat
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)\n\tat
> org.apache.solr.util.stats.MetricUtils.toMaps(MetricUtils.java:211)\n\tat
> org.apache.solr.handler.admin.MetricsHandler.handleRequestBody(MetricsHandler.java:108)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:735)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:716)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:497)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>
>
[jira] [Updated] (SOLR-12541) Metrics handler throws an error if there are transient cores
[
https://issues.apache.org/jira/browse/SOLR-12541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-12541:
--
Priority: Major (was: Blocker)
> Metrics handler throws an error if there are transient cores
>
>
> Key: SOLR-12541
> URL: https://issues.apache.org/jira/browse/SOLR-12541
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 7.2.1
>Reporter: Nandakishore Krishna
>Priority: Major
>
> My environment is as follows
> * Solr 7.2.1 in standalone mode.
> * 32GB heap
> * 150 cores with data getting continuously ingested to ~10 cores and all of
> the cores queried.
> * transient cache size is set to 30.
> The solr.xml is as follows
> {code:xml}
>
>
> 32
> true
> ${configSetBaseDir:configsets}
> class="HttpShardHandlerFactory">
> ${socketTimeout:60}
> ${connTimeout:6}
>
>
> {code}
> I get the following error when I request for "/solr/admin/metrics".
> {code}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 31
> },
> "error": {
> "msg": "Already closed",
> "trace": "org.apache.lucene.store.AlreadyClosedException: Already
> closed\n\tat
> org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:337)\n\tat
> org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:351)\n\tat
> org.apache.solr.core.SolrCore.getIndexDir(SolrCore.java:330)\n\tat
> org.apache.solr.handler.ReplicationHandler.lambda$initializeMetrics$5(ReplicationHandler.java:849)\n\tat
>
> org.apache.solr.util.stats.MetricUtils.convertGauge(MetricUtils.java:488)\n\tat
>
> org.apache.solr.util.stats.MetricUtils.convertMetric(MetricUtils.java:274)\n\tat
>
> org.apache.solr.util.stats.MetricUtils.lambda$toMaps$4(MetricUtils.java:213)\n\tat
>
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)\n\tat
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)\n\tat
>
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)\n\tat
> java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)\n\tat
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)\n\tat
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)\n\tat
>
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)\n\tat
>
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)\n\tat
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)\n\tat
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)\n\tat
> org.apache.solr.util.stats.MetricUtils.toMaps(MetricUtils.java:211)\n\tat
> org.apache.solr.handler.admin.MetricsHandler.handleRequestBody(MetricsHandler.java:108)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:735)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:716)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:497)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
>
[jira] [Commented] (LUCENE-8306) Allow iteration over the term positions of a Match
[ https://issues.apache.org/jira/browse/LUCENE-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545498#comment-16545498 ] Alan Woodward commented on LUCENE-8306: --- I ended up back where [~jimczi] suggested about a month ago. The attached patch adds two new methods to MatchesIterator: * label() - allows you to associate the current match with a top-level leaf query * getSubMatches() - returns another MatchesIterator over the individual term positions within the current match This doesn't expose terms, freqs or payloads. I figure let's try and keep the API as low-surface as possible for now, and see how far we get with highlighting. > Allow iteration over the term positions of a Match > -- > > Key: LUCENE-8306 > URL: https://issues.apache.org/jira/browse/LUCENE-8306 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8306.patch, LUCENE-8306.patch, LUCENE-8306.patch > > > For multi-term queries such as phrase queries, the matches API currently just > returns information about the span of the whole match. It would be useful to > also expose information about the matching terms within the phrase. The same > would apply to Spans and Interval queries. -- 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
[jira] [Updated] (LUCENE-8306) Allow iteration over the term positions of a Match
[ https://issues.apache.org/jira/browse/LUCENE-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-8306: -- Attachment: LUCENE-8306.patch > Allow iteration over the term positions of a Match > -- > > Key: LUCENE-8306 > URL: https://issues.apache.org/jira/browse/LUCENE-8306 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8306.patch, LUCENE-8306.patch, LUCENE-8306.patch > > > For multi-term queries such as phrase queries, the matches API currently just > returns information about the span of the whole match. It would be useful to > also expose information about the matching terms within the phrase. The same > would apply to Spans and Interval queries. -- 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
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545482#comment-16545482
]
Michael Braun commented on LUCENE-8402:
---
If it's a desired aspect of the test, could undo the work on that test and
ignore the forbidden api of Integer::new on the test class.
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Resolved] (LUCENE-8387) Add IndexSearcher.getSlices
[
https://issues.apache.org/jira/browse/LUCENE-8387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-8387.
Resolution: Fixed
Fix Version/s: 7.5
master (8.0)
> Add IndexSearcher.getSlices
> ---
>
> Key: LUCENE-8387
> URL: https://issues.apache.org/jira/browse/LUCENE-8387
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8387.patch, LUCENE-8387.patch
>
>
> When you pass an executor to {{IndexSearcher}}, it creates a {{LeafSlice[]}}
> slices, by default once slice per leaf, but a subclass can override. It's
> helpful to later be able to get those slices e.g. if you want to do your own
> concurrent per-slice processing.
> This patch will just add a getter to {{IndexSearcher}}, and make the
> {{LeafSlice.leaves}} member public.
--
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
[jira] [Resolved] (SOLR-12115) document the various types of domain changes in json faceting
[ https://issues.apache.org/jira/browse/SOLR-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-12115. - Resolution: Fixed Fix Version/s: 7.5 master (8.0) > document the various types of domain changes in json faceting > - > > Key: SOLR-12115 > URL: https://issues.apache.org/jira/browse/SOLR-12115 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: SOLR-12115.patch > > > I added query time join domain changes to json faceting in SOLR-10583 - but > didn't document it in the ref guide since json faceting iddn't exist in the > ref guide at all > we now have json faceting in the ref guide, but there isn't really a cohesive > section explaining domain changes - so it's still not trivial to add this > feature. > in general we should take responsibility for beefing up the docs on domain > changes, including the block join domain features (to parents & to children) > as well as this query domain change i added -- 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
[jira] [Commented] (SOLR-12115) document the various types of domain changes in json faceting
[ https://issues.apache.org/jira/browse/SOLR-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545435#comment-16545435 ] ASF subversion and git services commented on SOLR-12115: Commit 2b395dabb8cad934e5e8291ab63188ae16509e28 in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2b395da ] SOLR-12115: explain all the types of Domain changes available in JSON Faceting this also restructures the order of the content a bit to introduce concepts in the order they will most likelye be useful to most users > document the various types of domain changes in json faceting > - > > Key: SOLR-12115 > URL: https://issues.apache.org/jira/browse/SOLR-12115 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > Attachments: SOLR-12115.patch > > > I added query time join domain changes to json faceting in SOLR-10583 - but > didn't document it in the ref guide since json faceting iddn't exist in the > ref guide at all > we now have json faceting in the ref guide, but there isn't really a cohesive > section explaining domain changes - so it's still not trivial to add this > feature. > in general we should take responsibility for beefing up the docs on domain > changes, including the block join domain features (to parents & to children) > as well as this query domain change i added -- 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
[jira] [Commented] (SOLR-12115) document the various types of domain changes in json faceting
[ https://issues.apache.org/jira/browse/SOLR-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545434#comment-16545434 ] ASF subversion and git services commented on SOLR-12115: Commit ced5b7fe069d6b818b2e79fcfd3393f87db5b14e in lucene-solr's branch refs/heads/branch_7x from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ced5b7f ] SOLR-12115: explain all the types of Domain changes available in JSON Faceting this also restructures the order of the content a bit to introduce concepts in the order they will most likelye be useful to most users (cherry picked from commit 2b395dabb8cad934e5e8291ab63188ae16509e28) > document the various types of domain changes in json faceting > - > > Key: SOLR-12115 > URL: https://issues.apache.org/jira/browse/SOLR-12115 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Major > Attachments: SOLR-12115.patch > > > I added query time join domain changes to json faceting in SOLR-10583 - but > didn't document it in the ref guide since json faceting iddn't exist in the > ref guide at all > we now have json faceting in the ref guide, but there isn't really a cohesive > section explaining domain changes - so it's still not trivial to add this > feature. > in general we should take responsibility for beefing up the docs on domain > changes, including the block join domain features (to parents & to children) > as well as this query domain change i added -- 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
[jira] [Resolved] (LUCENE-8398) TieredMergePolicy.getMaxMergedSegmentMB has rounding error
[
https://issues.apache.org/jira/browse/LUCENE-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved LUCENE-8398.
Resolution: Fixed
Fix Version/s: 7.5
master (8.0)
> TieredMergePolicy.getMaxMergedSegmentMB has rounding error
> --
>
> Key: LUCENE-8398
> URL: https://issues.apache.org/jira/browse/LUCENE-8398
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8398.patch, LUCENE-8398.patch
>
>
> This is largely a test artifact since it's unlikely to show up for
> realistically sized segments, but the fix is simple and safe.
> This code first does long division then promotes to double for the last
> calculation.
> {code}
> return maxMergedSegmentBytes/1024/1024.;
> {code}
> The error can be reproduced with: -Dtests.seed=EF80BCABAD74A7CF
--
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
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1586 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1586/ 7 tests failed. FAILED: org.apache.lucene.document.TestLatLonShapeQueries.testRandomBig Error Message: GC overhead limit exceeded Stack Trace: java.lang.OutOfMemoryError: GC overhead limit exceeded at __randomizedtesting.SeedInfo.seed([DBDFEBB87CF9EF8A:5C889637EDA0930A]:0) at org.apache.lucene.geo.Polygon.(Polygon.java:94) at org.apache.lucene.geo.GeoTestUtil.surpriseMePolygon(GeoTestUtil.java:520) at org.apache.lucene.geo.GeoTestUtil.nextPolygon(GeoTestUtil.java:390) at org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:127) at org.apache.lucene.document.TestLatLonShapeQueries.testRandomBig(TestLatLonShapeQueries.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test Error Message: document count mismatch. control=362 sum(shards)=363 cloudClient=363 Stack Trace: java.lang.AssertionError: document count mismatch. control=362 sum(shards)=363 cloudClient=363 at __randomizedtesting.SeedInfo.seed([868266198AEB55B7:ED659C32417384F]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1382) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:275) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+22) - Build # 2331 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2331/ Java: 64bit/jdk-11-ea+22 -XX:-UseCompressedOops -XX:+UseSerialGC 80 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.DocValuesNotIndexedTest Error Message: Collection not found: dv_coll Stack Trace: org.apache.solr.common.SolrException: Collection not found: dv_coll at __randomizedtesting.SeedInfo.seed([C94FD5C4FF7E29A8]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:853) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.cloud.DocValuesNotIndexedTest.createCluster(DocValuesNotIndexedTest.java:154) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.DocValuesNotIndexedTest Error Message: Collection not found: dv_coll Stack Trace: org.apache.solr.common.SolrException: Collection not found: dv_coll at __randomizedtesting.SeedInfo.seed([C94FD5C4FF7E29A8]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:853) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.cloud.DocValuesNotIndexedTest.createCluster(DocValuesNotIndexedTest.java:154) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at
[jira] [Commented] (LUCENE-8398) TieredMergePolicy.getMaxMergedSegmentMB has rounding error
[
https://issues.apache.org/jira/browse/LUCENE-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545354#comment-16545354
]
ASF subversion and git services commented on LUCENE-8398:
-
Commit 7cddc0569341209e2569d079d7a2f4d772cb017b in lucene-solr's branch
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7cddc05 ]
LUCENE-8398: TieredMergePolicy.getMaxMergedSegmentMB has rounding error
(cherry picked from commit 8ce46b6)
> TieredMergePolicy.getMaxMergedSegmentMB has rounding error
> --
>
> Key: LUCENE-8398
> URL: https://issues.apache.org/jira/browse/LUCENE-8398
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-8398.patch, LUCENE-8398.patch
>
>
> This is largely a test artifact since it's unlikely to show up for
> realistically sized segments, but the fix is simple and safe.
> This code first does long division then promotes to double for the last
> calculation.
> {code}
> return maxMergedSegmentBytes/1024/1024.;
> {code}
> The error can be reproduced with: -Dtests.seed=EF80BCABAD74A7CF
--
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
[jira] [Commented] (LUCENE-8398) TieredMergePolicy.getMaxMergedSegmentMB has rounding error
[
https://issues.apache.org/jira/browse/LUCENE-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545329#comment-16545329
]
ASF subversion and git services commented on LUCENE-8398:
-
Commit 8ce46b6c45d744b3b1119afd447a532122fd4760 in lucene-solr's branch
refs/heads/master from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8ce46b6 ]
LUCENE-8398: TieredMergePolicy.getMaxMergedSegmentMB has rounding error
> TieredMergePolicy.getMaxMergedSegmentMB has rounding error
> --
>
> Key: LUCENE-8398
> URL: https://issues.apache.org/jira/browse/LUCENE-8398
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-8398.patch, LUCENE-8398.patch
>
>
> This is largely a test artifact since it's unlikely to show up for
> realistically sized segments, but the fix is simple and safe.
> This code first does long division then promotes to double for the last
> calculation.
> {code}
> return maxMergedSegmentBytes/1024/1024.;
> {code}
> The error can be reproduced with: -Dtests.seed=EF80BCABAD74A7CF
--
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
[jira] [Created] (SOLR-12555) Replace try-fail-catch test patterns
Jason Gerlowski created SOLR-12555:
--
Summary: Replace try-fail-catch test patterns
Key: SOLR-12555
URL: https://issues.apache.org/jira/browse/SOLR-12555
Project: Solr
Issue Type: Test
Security Level: Public (Default Security Level. Issues are Public)
Components: Tests
Affects Versions: master (8.0)
Reporter: Jason Gerlowski
Assignee: Jason Gerlowski
I recently added some test code through SOLR-12427 which used the following
test anti-pattern:
{code}
try {
actionExpectedToThrowException();
fail("I expected this to throw an exception, but it didn't");
catch (Exception e) {
assertOnThrownException(e);
}
{code}
Hoss (rightfully) objected that this should instead be written using the
formulation below, which is clearer and more concise.
{code}
SolrException e = expectThrows(() -> {...});
{code}
We should remove many of these older formulations where it makes sense. Many
of them were written before {{expectThrows}} was introduced, and having the old
style assertions around makes it easier for them to continue creeping in.
--
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
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1972 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1972/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.lucene.util.TestPriorityQueue.testIteratorRandom Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([8D26D76C882C063:7E94FDA5A4CE3759]:0) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28) at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264) at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141) at org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.lucene.util.TestPriorityQueue.testIteratorRandom Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([8D26D76C882C063:7E94FDA5A4CE3759]:0) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28) at
Badapple report
I have a note _not_ to disable CdcrBidirectionalTest.testBiDir, but it's failing a lot. Anyone working on it? In general, CdcrReplicationDistributedZkTest is totally bad. It runs @Nightly, but fails 100% of the time and has for months. Is anyone actively working on this? I'm having a bit of trouble with suite annotations, even though I BadApple some of them they still seem to come through. I'll dig when I have time, meanwhile suite annotations are sometimes noise. **Annotations will be removed from the following tests because they haven't failed in the last month. **Methods: 12 HdfsBasicDistributedZk2Test HdfsBasicDistributedZkTest MultiThreadedOCPTest.test TestCollectionStateWatchers.testCanWaitForNonexistantCollection TestCollectionStateWatchers.testDeletionsTriggerWatches TestCollectionStateWatchers.testPredicateFailureTimesOut TestCollectionStateWatchers.testStateWatcherChecksCurrentStateOnRegister TestCollectionStateWatchers.testWatcherIsRemovedAfterTimeout TestReplicationHandler TestSimDistributedQueue.testDistributedQueue TestSolrCloudWithHadoopAuthPlugin TestTriggerIntegration.testNodeLostTrigger Test's I'll annotate this week. 0123 1.2 1525 9 HdfsAutoAddReplicasIntegrationTest.testSimple 0123 70.6 82 60 HdfsTlogReplayBufferedWhileIndexingTest(suite) 0123 0.3 1805 12 MathExpressionTest.testDistributions 0123 0.5 1750 12 MetricsHistoryHandlerTest(suite) 0123 3.8 1720 92 MoveReplicaHDFSTest.testFailedMove 0123 0.8 1740 8 ReplicationFactorTest.test 0123 0.8 1538 13 ScheduledTriggerTest.testTrigger 0123 74.1 108 80 SharedFSAutoReplicaFailoverTest(suite) 0123 17.6 151 11 SharedFSAutoReplicaFailoverTest.test 0123 14.8 1789 80 StreamDecoratorTest(suite) 0123 0.8 1790 10 TestCloudRecovery.leaderRecoverFromLogOnStartupTest 0123 5.9 1734 37 TestDynamicLoading.testDynamicLoading 0123 3.0 134 11 TestGenericDistributedQueue.testDistributedQueue 0123 2.6 597 16 TestHdfsCloudBackupRestore.test 0123 2.3 1824 60 TestLocalFSCloudBackupRestore.test 0123 2.3 1775 28 TestNamedUpdateProcessors.test 0123 0.3 1774 4 TestPullReplicaErrorHandling.testCantConnectToPullReplica 0123 0.3 1809 4 TestSolrEntityProcessorEndToEnd.testFullImport 0123 0.8 1775195 TestStressCloudBlindAtomicUpdates(suite) 0123 0.8 1808 18 TestStressCloudBlindAtomicUpdates.test_dv_idx Full report attached. DO NOT ENABLE LIST: 'IndexSizeTriggerTest.testMergeIntegration' 'IndexSizeTriggerTest.testMixedBounds' 'IndexSizeTriggerTest.testSplitIntegration' 'IndexSizeTriggerTest.testTrigger' 'TestControlledRealTimeReopenThread.testCRTReopen' 'TestICUNormalizer2CharFilter.testRandomStrings' 'TestICUTokenizerCJK' 'TestImpersonationWithHadoopAuth.testForwarding' 'TestLTRReRankingPipeline.testDifferentTopN' 'TestRandomChains' DO NOT ANNOTATE LIST CdcrBidirectionalTest.testBiDir TestRandomChains.testRandomChainsWithLargeStrings Processing file (History bit 3): HOSS-2018-07-16.csv Processing file (History bit 2): HOSS-2018-07-09.csv Processing file (History bit 1): HOSS-2018-07-02.csv Processing file (History bit 0): HOSS-2018-06-25.csv **Annotated tests/suites that didn't fail in the last 4 weeks. **Tests and suites removed from the next two lists because they were specified in 'doNotEnable' in the properties file no tests removed **Annotations will be removed from the following tests because they haven't failed in the last month. **Methods: 12 HdfsBasicDistributedZk2Test HdfsBasicDistributedZkTest MultiThreadedOCPTest.test TestCollectionStateWatchers.testCanWaitForNonexistantCollection TestCollectionStateWatchers.testDeletionsTriggerWatches TestCollectionStateWatchers.testPredicateFailureTimesOut TestCollectionStateWatchers.testStateWatcherChecksCurrentStateOnRegister TestCollectionStateWatchers.testWatcherIsRemovedAfterTimeout TestReplicationHandler TestSimDistributedQueue.testDistributedQueue TestSolrCloudWithHadoopAuthPlugin TestTriggerIntegration.testNodeLostTrigger **Suites: 0 Failures in Hoss' reports for the last 4 collected reports. There were 809 unannotated tests that failed in Hoss' rollups. Ordered by the date I downloaded the rollup file, newest->oldest. See above for the dates the files were collected These tests were NOT BadApple'd or AwaitsFix'd All tests that failed 4 weeks running will be BadApple'd unless there are objections Failures in the last 4 reports.. Report Pct runsfails test 0123 13.6 2004177 CdcrBidirectionalTest.testBiDir 0123 1.2 1525 9
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 22463 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22463/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC 5 tests failed. FAILED: org.apache.lucene.util.TestPriorityQueue.testIteratorRandom Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([AE039D81F02325E0:D8450D529C6FD2DA]:0) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28) at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264) at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141) at org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.lucene.util.TestPriorityQueue.testIteratorRandom Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([AE039D81F02325E0:D8450D529C6FD2DA]:0) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28) at
[JENKINS] Lucene-Solr-Tests-7.x - Build # 683 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/683/ 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost Error Message: org.apache.solr.common.SolrException: Stack Trace: org.apache.solr.common.SolrException: org.apache.solr.common.SolrException: at __randomizedtesting.SeedInfo.seed([1D38324E7363FDC2:A22DFCB0F0899844]:0) at org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:78) at org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:130) at org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:122) at org.apache.solr.cloud.autoscaling.ComputePlanActionTest.printState(ComputePlanActionTest.java:151) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.solr.common.SolrException: at org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:291) at
[jira] [Commented] (SOLR-12519) Support Deeply Nested Docs In Child Documents Transformer
[
https://issues.apache.org/jira/browse/SOLR-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545208#comment-16545208
]
David Smiley commented on SOLR-12519:
-
You're correct that we might _inadvertently_ have a situation where the bits
get produced twice, though I don't think we need to modify Lucene (e.g.
ToChildBlockJoinWeight) to address that.
QueryBitSetProducer internally has a cache, but it wont be leveraged unless we
retain QueryBitSetProducer. We could either address that -- cache these things
(Query->QBSP) somewhere, or don't use QueryBitSetProducer and instead leverage
Solr's own filter cache. There's even a TODO in ChildDocTransformer to this
effect. Oh yeah, I added that TODO June 1st :-) See
org.apache.solr.search.join.BlockJoinParentQParser#getCachedFilter for a clue.
> Support Deeply Nested Docs In Child Documents Transformer
> -
>
> Key: SOLR-12519
> URL: https://issues.apache.org/jira/browse/SOLR-12519
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12519-no-commit.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As discussed in SOLR-12298, to make use of the meta-data fields in
> SOLR-12441, there needs to be a smarter child document transformer, which
> provides the ability to rebuild the original nested documents' structure.
> In addition, I also propose the transformer will also have the ability to
> bring only some of the original hierarchy, to prevent unnecessary block join
> queries. e.g.
> {code} {"a": "b", "c": [ {"e": "f"}, {"e": "g"} , {"h": "i"} ]} {code}
> Incase my query is for all the children of "a:b", which contain the key "e"
> in them, the query will be broken in to two parts:
> 1. The parent query "a:b"
> 2. The child query "e:*".
> If the only children flag is on, the transformer will return the following
> documents:
> {code}[ {"e": "f"}, {"e": "g"} ]{code}
> In case the flag was not turned on(perhaps the default state), the whole
> document hierarchy will be returned, containing only the matching children:
> {code}{"a": "b", "c": [ {"e": "f"}, {"e": "g"} ]{code}
--
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
[jira] [Issue Comment Deleted] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ferenczi updated LUCENE-8402:
-
Comment: was deleted
(was: Found by the build in
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2330
I muted the test on master and branch_7x for now.)
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545158#comment-16545158
]
Jim Ferenczi commented on LUCENE-8402:
--
Found by the build in https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2330
I muted the test on master and branch_7x for now.
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545159#comment-16545159
]
Jim Ferenczi commented on LUCENE-8402:
--
Found by the build in https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2330
I muted the test on master and branch_7x for now.
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545155#comment-16545155
]
ASF subversion and git services commented on LUCENE-8402:
-
Commit 5d546adc0724ca2ec9cd1b836dedd5dc76ab5fc5 in lucene-solr's branch
refs/heads/branch_7x from [~jim.ferenczi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5d546ad ]
LUCENE-8402: Mute test
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545152#comment-16545152
]
ASF subversion and git services commented on LUCENE-8402:
-
Commit 4b9e2c406e99ef40efbed8181dbb71dff263b876 in lucene-solr's branch
refs/heads/master from [~jim.ferenczi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4b9e2c4 ]
LUCENE-8402: Mute test
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 2330 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2330/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.lucene.util.TestPriorityQueue.testIteratorRandom Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([1724906FE95A9A24:616200BC85166D1E]:0) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28) at org.apache.lucene.util.PriorityQueue.downHeap(PriorityQueue.java:277) at org.apache.lucene.util.PriorityQueue.pop(PriorityQueue.java:185) at org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:244) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.lucene.util.TestPriorityQueue.testIteratorRandom Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([1724906FE95A9A24:616200BC85166D1E]:0) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36) at org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28) at org.apache.lucene.util.PriorityQueue.downHeap(PriorityQueue.java:277)
[jira] [Commented] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545121#comment-16545121
]
Jim Ferenczi commented on LUCENE-8402:
--
Here is a patch that removes the assertions around reused Integers.
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Updated] (LUCENE-8402) TestPriorityQueue failures
[
https://issues.apache.org/jira/browse/LUCENE-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ferenczi updated LUCENE-8402:
-
Attachment: LUCENE-8402.patch
> TestPriorityQueue failures
> --
>
> Key: LUCENE-8402
> URL: https://issues.apache.org/jira/browse/LUCENE-8402
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8402.patch
>
>
> Elastic CI found a couple of failures in TestPriorityQueue:
> {code}
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
> at
> org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
> at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
> at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
> at
> org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
> {code}
> It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
> It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
> the deprecated call to "new Integer" despite the fact that the queue in the
> tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Created] (LUCENE-8402) TestPriorityQueue failures
Jim Ferenczi created LUCENE-8402:
Summary: TestPriorityQueue failures
Key: LUCENE-8402
URL: https://issues.apache.org/jira/browse/LUCENE-8402
Project: Lucene - Core
Issue Type: Test
Reporter: Jim Ferenczi
Elastic CI found a couple of failures in TestPriorityQueue:
{code}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([7116E1C3DFA51E99:7507110B3E9E9A3]:0)
at
org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:36)
at
org.apache.lucene.util.TestPriorityQueue$IntegerQueue.lessThan(TestPriorityQueue.java:28)
at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:264)
at org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:141)
at
org.apache.lucene.util.TestPriorityQueue.testIteratorRandom(TestPriorityQueue.java:241)
{code}
It can be reproduced with the following seed: -Dtests.seed=7116E1C3DFA51E99
It is due to https://issues.apache.org/jira/browse/LUCENE-8345 which removed
the deprecated call to "new Integer" despite the fact that the queue in the
tests (IntegerQueue#lessThan) does not allow to reuse Integers.
--
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
[jira] [Resolved] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-8345. --- Resolution: Fixed Fix Version/s: 7.5 master (8.0) > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Fix For: master (8.0), 7.5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545049#comment-16545049 ] ASF subversion and git services commented on LUCENE-8345: - Commit 8f209f66ff7494567c355900657aa883d653b9a8 in lucene-solr's branch refs/heads/branch_7x from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8f209f6 ] Merge branch 'remove-constructor-wrapper-classes' of https://github.com/michaelbraun/lucene-solr: LUCENE-8345, GitHub PR #392: Remove instantiation of redundant wrapper classes for primitives; add wrapper class constructors to forbiddenapis. This closes #392 > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545050#comment-16545050 ] Uwe Schindler commented on LUCENE-8345: --- Hi, forbiddenapis was happy after the cherry-pick. I pushed the changes to 7.x, too. Thanks [~mbraun688]! > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545043#comment-16545043 ] Uwe Schindler commented on LUCENE-8345: --- The cherry-pick worked without any conflicts. I am now running forbiddenapis to find any additional violations in branch_7x. If there are none, I will push the changes ASAP. > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Comment Edited] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545041#comment-16545041 ] Uwe Schindler edited comment on LUCENE-8345 at 7/16/18 10:28 AM: - Hi, I merged your branch into master and closed the PR. I will let jenkins run for a few hours and then try to cherry-pick to branch_7x. If there are major problems (quite many files touches), I will contact you, [~mbraun688]. No need to take action now. was (Author: thetaphi): Hi, I mreged your branch into master and closed the PR. I will let jenkins run for a few hours and then try to cherry-pick to branch_7x. If there are major problems (quite many files touches), I will contact you, [~mbraun688]. No need to take action now. > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545041#comment-16545041 ] Uwe Schindler commented on LUCENE-8345: --- Hi, I mreged your branch into master and closed the PR. I will let jenkins run for a few hours and then try to cherry-pick to branch_7x. If there are major problems (quite many files touches), I will contact you, [~mbraun688]. No need to take action now. > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Commented] (LUCENE-8401) Add PassageBuilder to help construct highlights using MatchesIterator
[ https://issues.apache.org/jira/browse/LUCENE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545040#comment-16545040 ] Alan Woodward commented on LUCENE-8401: --- Here is a patch containing the following classes: * Passage -> a representation of a highlight snippet, with text, start and end offset, and a list of internal hits * PassageBreaker -> an interface that defines where passages should start and end, and if a hit should be added to the current passage or should start a new one * PassageBuilder -> public API that iteratively returns new Passage objects * BreakIteratorPassageBreaker -> simple implementation of PassageBreaker The passage builder uses a wrapper around its MatchesIterator to enable it to peek at the position of the next hit, which means that we can improve clustering for hits that looks like [A .. B .. C], where A and B are within the maximum snippet size, but A and C are not. > Add PassageBuilder to help construct highlights using MatchesIterator > - > > Key: LUCENE-8401 > URL: https://issues.apache.org/jira/browse/LUCENE-8401 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/highlighter >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8401.patch > > > Jim and I discussed a while back the idea of adding highlighter components, > rather than a fully-fledged highlighter, which would allow users to build > their own specialised highlighters. To that end, I'd like to add a > PassageBuilder class that uses the Matches API to break text up into passages > containing hits. -- 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
[GitHub] lucene-solr pull request #392: LUCENE-8345 - add wrapper class constructors ...
Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/392 --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545039#comment-16545039 ] ASF subversion and git services commented on LUCENE-8345: - Commit c97f27b06c1d7c250e9596a9bc7bf5ca11ef6ad3 in lucene-solr's branch refs/heads/master from [~thetaphi] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c97f27b ] Merge branch 'remove-constructor-wrapper-classes' of https://github.com/michaelbraun/lucene-solr: LUCENE-8345, GitHub PR #392: Remove instantiation of redundant wrapper classes for primitives; add wrapper class constructors to forbiddenapis. This closes #392 > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis
[ https://issues.apache.org/jira/browse/LUCENE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545038#comment-16545038 ] ASF subversion and git services commented on LUCENE-8345: - Commit fb6574100e493ed9162265133f2cbe967746c166 in lucene-solr's branch refs/heads/master from Michael Braun [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb65741 ] LUCENE-8345 - add wrapper class constructors to forbiddenapis > Add wrapper class constructors to forbiddenapis > --- > > Key: LUCENE-8345 > URL: https://issues.apache.org/jira/browse/LUCENE-8345 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael Braun >Assignee: Uwe Schindler >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, > Integer, Long, Float, Double) have constructors which will always create new > objects. These constructors are officially deprecated as of Java 9 and it is > recommended to use the public static methods since these can reuse the same > underlying objects. In 99% of cases we should be doing this, so these > constructors should be added to forbiddenapis and code corrected to use > autoboxing or call the static methods (.valueOf, .parse*) explicitly. -- 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
[jira] [Updated] (LUCENE-8401) Add PassageBuilder to help construct highlights using MatchesIterator
[ https://issues.apache.org/jira/browse/LUCENE-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-8401: -- Attachment: LUCENE-8401.patch > Add PassageBuilder to help construct highlights using MatchesIterator > - > > Key: LUCENE-8401 > URL: https://issues.apache.org/jira/browse/LUCENE-8401 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/highlighter >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8401.patch > > > Jim and I discussed a while back the idea of adding highlighter components, > rather than a fully-fledged highlighter, which would allow users to build > their own specialised highlighters. To that end, I'd like to add a > PassageBuilder class that uses the Matches API to break text up into passages > containing hits. -- 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
[jira] [Created] (LUCENE-8401) Add PassageBuilder to help construct highlights using MatchesIterator
Alan Woodward created LUCENE-8401: - Summary: Add PassageBuilder to help construct highlights using MatchesIterator Key: LUCENE-8401 URL: https://issues.apache.org/jira/browse/LUCENE-8401 Project: Lucene - Core Issue Type: New Feature Components: modules/highlighter Reporter: Alan Woodward Assignee: Alan Woodward Jim and I discussed a while back the idea of adding highlighter components, rather than a fully-fledged highlighter, which would allow users to build their own specialised highlighters. To that end, I'd like to add a PassageBuilder class that uses the Matches API to break text up into passages containing hits. -- 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
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4736 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4736/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium Error Message: wrong hit (first of possibly more): FAIL: id=2503 should match but did not query=LatLonShapeBoundingBoxQuery: field=shape:Rectangle(lat=-44.92331048939377 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) docID=2436 polygon=[-4.190951585769653E-8, 0.0] [89.9995809048, 0.0] [89.9995809048, 179.9991618097] [-4.190951585769653E-8, 0.0] deleted?=false rect=Rectangle(-44.92331048939377 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) Stack Trace: java.lang.AssertionError: wrong hit (first of possibly more): FAIL: id=2503 should match but did not query=LatLonShapeBoundingBoxQuery: field=shape:Rectangle(lat=-44.92331048939377 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) docID=2436 polygon=[-4.190951585769653E-8, 0.0] [89.9995809048, 0.0] [89.9995809048, 179.9991618097] [-4.190951585769653E-8, 0.0] deleted?=false rect=Rectangle(-44.92331048939377 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) at __randomizedtesting.SeedInfo.seed([62D13477D093226D:DF0F03DF91F6410B]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.document.TestLatLonShapeQueries.verifyRandomBBoxes(TestLatLonShapeQueries.java:263) at org.apache.lucene.document.TestLatLonShapeQueries.verify(TestLatLonShapeQueries.java:134) at org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:130) at org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium(TestLatLonShapeQueries.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at
[jira] [Commented] (LUCENE-8400) Make BytesRefHash.compact public and @lucene.internal
[
https://issues.apache.org/jira/browse/LUCENE-8400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545030#comment-16545030
]
Adrien Grand commented on LUCENE-8400:
--
I don't mind making it public. The whole class is already tagged with
@lucene.internal anyway.
> Make BytesRefHash.compact public and @lucene.internal
> -
>
> Key: LUCENE-8400
> URL: https://issues.apache.org/jira/browse/LUCENE-8400
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Major
>
> {{BytesRefHash}} is an internal Lucene class, essentially providing a compact
> representation of {{Map}}. It already has a public {{sort}}
> method, which destructively compacts all entries and returns them, but its
> {{compact}} method (which compacts all entries without the cost of sorting)
> is not public ... I'd like to make it public, and also mark it
> {{@lucene.internal}}.
--
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
[jira] [Created] (LUCENE-8400) Make BytesRefHash.compact public and @lucene.internal
Michael McCandless created LUCENE-8400:
--
Summary: Make BytesRefHash.compact public and @lucene.internal
Key: LUCENE-8400
URL: https://issues.apache.org/jira/browse/LUCENE-8400
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
{{BytesRefHash}} is an internal Lucene class, essentially providing a compact
representation of {{Map}}. It already has a public {{sort}}
method, which destructively compacts all entries and returns them, but its
{{compact}} method (which compacts all entries without the cost of sorting) is
not public ... I'd like to make it public, and also mark it
{{@lucene.internal}}.
--
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
[jira] [Commented] (LUCENE-8398) TieredMergePolicy.getMaxMergedSegmentMB has rounding error
[
https://issues.apache.org/jira/browse/LUCENE-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16545017#comment-16545017
]
Michael McCandless commented on LUCENE-8398:
+1
> TieredMergePolicy.getMaxMergedSegmentMB has rounding error
> --
>
> Key: LUCENE-8398
> URL: https://issues.apache.org/jira/browse/LUCENE-8398
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-8398.patch, LUCENE-8398.patch
>
>
> This is largely a test artifact since it's unlikely to show up for
> realistically sized segments, but the fix is simple and safe.
> This code first does long division then promotes to double for the last
> calculation.
> {code}
> return maxMergedSegmentBytes/1024/1024.;
> {code}
> The error can be reproduced with: -Dtests.seed=EF80BCABAD74A7CF
--
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
[JENKINS] Lucene-Solr-Tests-master - Build # 2606 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2606/ 2 tests failed. FAILED: org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium Error Message: wrong hit (first of possibly more): FAIL: id=12522 should match but did not query=LatLonShapeBoundingBoxQuery: field=shape:Rectangle(lat=0.0 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) docID=5883 polygon=[-4.190951585769653E-8, 0.0] [89.9995809048, 0.0] [89.9995809048, 179.9991618097] [-4.190951585769653E-8, 0.0] deleted?=false rect=Rectangle(0.0 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) Stack Trace: java.lang.AssertionError: wrong hit (first of possibly more): FAIL: id=12522 should match but did not query=LatLonShapeBoundingBoxQuery: field=shape:Rectangle(lat=0.0 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) docID=5883 polygon=[-4.190951585769653E-8, 0.0] [89.9995809048, 0.0] [89.9995809048, 179.9991618097] [-4.190951585769653E-8, 0.0] deleted?=false rect=Rectangle(0.0 TO 0.0 lon=8.381903171539307E-8 TO 0.999403953552) at __randomizedtesting.SeedInfo.seed([5418656F19DF192:B89FB1FEB0F892F4]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.document.TestLatLonShapeQueries.verifyRandomBBoxes(TestLatLonShapeQueries.java:263) at org.apache.lucene.document.TestLatLonShapeQueries.verify(TestLatLonShapeQueries.java:134) at org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:130) at org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium(TestLatLonShapeQueries.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at
[jira] [Commented] (LUCENE-8399) TestLatLonShapeQuerie failures
[
https://issues.apache.org/jira/browse/LUCENE-8399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544986#comment-16544986
]
ASF subversion and git services commented on LUCENE-8399:
-
Commit b6d6f1e3b51d217034d92175e8358cb0035801f7 in lucene-solr's branch
refs/heads/master from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b6d6f1e ]
LUCENE-8399: Disable test.
> TestLatLonShapeQuerie failures
> --
>
> Key: LUCENE-8399
> URL: https://issues.apache.org/jira/browse/LUCENE-8399
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Adrien Grand
>Priority: Major
>
> The build found a couple of reproducing seed, eg. this one on 7.x:
> https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2328/.
> {noformat}
> FAILED: org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium
> Error Message:
> wrong hit (first of possibly more): FAIL: id=6472 should match but did not
> query=LatLonShapeBoundingBoxQuery:
> field=shape:Rectangle(lat=-62.921879715286195 TO 0.0 lon=8.381903171539307E-8
> TO 0.999403953552) docID=15772 polygon=[-4.190951585769653E-8, 0.0]
> [89.9995809048, 0.0] [89.9995809048, 179.9991618097]
> [-4.190951585769653E-8, 0.0]deleted?=false
> rect=Rectangle(-62.921879715286195 TO 0.0 lon=8.381903171539307E-8 TO
> 0.999403953552)
> Stack Trace:
> java.lang.AssertionError: wrong hit (first of possibly more):
> FAIL: id=6472 should match but did not
> query=LatLonShapeBoundingBoxQuery:
> field=shape:Rectangle(lat=-62.921879715286195 TO 0.0 lon=8.381903171539307E-8
> TO 0.999403953552) docID=15772
> polygon=[-4.190951585769653E-8, 0.0] [89.9995809048, 0.0]
> [89.9995809048, 179.9991618097] [-4.190951585769653E-8, 0.0]
> deleted?=false rect=Rectangle(-62.921879715286195 TO 0.0
> lon=8.381903171539307E-8 TO 0.999403953552)
> at
> __randomizedtesting.SeedInfo.seed([B1406AEE368F6B32:C9E5D4677EA0854]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.verifyRandomBBoxes(TestLatLonShapeQueries.java:262)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.verify(TestLatLonShapeQueries.java:133)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:129)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium(TestLatLonShapeQueries.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
>
[jira] [Commented] (LUCENE-8399) TestLatLonShapeQuerie failures
[
https://issues.apache.org/jira/browse/LUCENE-8399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544985#comment-16544985
]
ASF subversion and git services commented on LUCENE-8399:
-
Commit bbef7e2091ab608e6529522e2b814d609eef5d98 in lucene-solr's branch
refs/heads/branch_7x from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bbef7e2 ]
LUCENE-8399: Disable test.
> TestLatLonShapeQuerie failures
> --
>
> Key: LUCENE-8399
> URL: https://issues.apache.org/jira/browse/LUCENE-8399
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Adrien Grand
>Priority: Major
>
> The build found a couple of reproducing seed, eg. this one on 7.x:
> https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2328/.
> {noformat}
> FAILED: org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium
> Error Message:
> wrong hit (first of possibly more): FAIL: id=6472 should match but did not
> query=LatLonShapeBoundingBoxQuery:
> field=shape:Rectangle(lat=-62.921879715286195 TO 0.0 lon=8.381903171539307E-8
> TO 0.999403953552) docID=15772 polygon=[-4.190951585769653E-8, 0.0]
> [89.9995809048, 0.0] [89.9995809048, 179.9991618097]
> [-4.190951585769653E-8, 0.0]deleted?=false
> rect=Rectangle(-62.921879715286195 TO 0.0 lon=8.381903171539307E-8 TO
> 0.999403953552)
> Stack Trace:
> java.lang.AssertionError: wrong hit (first of possibly more):
> FAIL: id=6472 should match but did not
> query=LatLonShapeBoundingBoxQuery:
> field=shape:Rectangle(lat=-62.921879715286195 TO 0.0 lon=8.381903171539307E-8
> TO 0.999403953552) docID=15772
> polygon=[-4.190951585769653E-8, 0.0] [89.9995809048, 0.0]
> [89.9995809048, 179.9991618097] [-4.190951585769653E-8, 0.0]
> deleted?=false rect=Rectangle(-62.921879715286195 TO 0.0
> lon=8.381903171539307E-8 TO 0.999403953552)
> at
> __randomizedtesting.SeedInfo.seed([B1406AEE368F6B32:C9E5D4677EA0854]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.verifyRandomBBoxes(TestLatLonShapeQueries.java:262)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.verify(TestLatLonShapeQueries.java:133)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:129)
> at
> org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium(TestLatLonShapeQueries.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
>
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_172) - Build # 2329 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2329/ Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild Error Message: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException Stack Trace: java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException at __randomizedtesting.SeedInfo.seed([DC08979674FE7D0B:385F5294A972869]:0) at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: junit.framework.AssertionFailedError: Unexpected
[jira] [Created] (LUCENE-8399) TestLatLonShapeQuerie failures
Adrien Grand created LUCENE-8399:
Summary: TestLatLonShapeQuerie failures
Key: LUCENE-8399
URL: https://issues.apache.org/jira/browse/LUCENE-8399
Project: Lucene - Core
Issue Type: Test
Reporter: Adrien Grand
The build found a couple of reproducing seed, eg. this one on 7.x:
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2328/.
{noformat}
FAILED: org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium
Error Message:
wrong hit (first of possibly more): FAIL: id=6472 should match but did not
query=LatLonShapeBoundingBoxQuery:
field=shape:Rectangle(lat=-62.921879715286195 TO 0.0 lon=8.381903171539307E-8
TO 0.999403953552) docID=15772 polygon=[-4.190951585769653E-8, 0.0]
[89.9995809048, 0.0] [89.9995809048, 179.9991618097]
[-4.190951585769653E-8, 0.0]deleted?=false
rect=Rectangle(-62.921879715286195 TO 0.0 lon=8.381903171539307E-8 TO
0.999403953552)
Stack Trace:
java.lang.AssertionError: wrong hit (first of possibly more):
FAIL: id=6472 should match but did not
query=LatLonShapeBoundingBoxQuery:
field=shape:Rectangle(lat=-62.921879715286195 TO 0.0 lon=8.381903171539307E-8
TO 0.999403953552) docID=15772
polygon=[-4.190951585769653E-8, 0.0] [89.9995809048, 0.0]
[89.9995809048, 179.9991618097] [-4.190951585769653E-8, 0.0]
deleted?=false rect=Rectangle(-62.921879715286195 TO 0.0
lon=8.381903171539307E-8 TO 0.999403953552)
at
__randomizedtesting.SeedInfo.seed([B1406AEE368F6B32:C9E5D4677EA0854]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.document.TestLatLonShapeQueries.verifyRandomBBoxes(TestLatLonShapeQueries.java:262)
at
org.apache.lucene.document.TestLatLonShapeQueries.verify(TestLatLonShapeQueries.java:133)
at
org.apache.lucene.document.TestLatLonShapeQueries.doTestRandom(TestLatLonShapeQueries.java:129)
at
org.apache.lucene.document.TestLatLonShapeQueries.testRandomMedium(TestLatLonShapeQueries.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
[jira] [Commented] (LUCENE-8398) TieredMergePolicy.getMaxMergedSegmentMB has rounding error
[
https://issues.apache.org/jira/browse/LUCENE-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544974#comment-16544974
]
Adrien Grand commented on LUCENE-8398:
--
+1
> TieredMergePolicy.getMaxMergedSegmentMB has rounding error
> --
>
> Key: LUCENE-8398
> URL: https://issues.apache.org/jira/browse/LUCENE-8398
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-8398.patch, LUCENE-8398.patch
>
>
> This is largely a test artifact since it's unlikely to show up for
> realistically sized segments, but the fix is simple and safe.
> This code first does long division then promotes to double for the last
> calculation.
> {code}
> return maxMergedSegmentBytes/1024/1024.;
> {code}
> The error can be reproduced with: -Dtests.seed=EF80BCABAD74A7CF
--
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
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-10.0.1) - Build # 693 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/693/ Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.EchoParamsTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.EchoParamsTest_289860A7CDF70B00-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.EchoParamsTest_289860A7CDF70B00-001\init-core-data-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.EchoParamsTest_289860A7CDF70B00-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.EchoParamsTest_289860A7CDF70B00-001\init-core-data-001 at __randomizedtesting.SeedInfo.seed([289860A7CDF70B00]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 1843 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\temp\junit4-J1-20180716_065107_083970718034932772.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 5 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\core\test\temp\junit4-J0-20180716_065107_08215606475818025163212.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 313 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\temp\junit4-J1-20180716_065742_3656057690882672093066.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\temp\junit4-J0-20180716_065742_36517516921182037504673.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 1082 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\analysis\common\test\temp\junit4-J0-20180716_065837_55410929563881963555099.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\analysis\common\test\temp\junit4-J1-20180716_065837_5543552922514361814539.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning:
[jira] [Commented] (SOLR-11986) Allow percentage in freedisk attribute in autoscaling policy rules
[
https://issues.apache.org/jira/browse/SOLR-11986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544923#comment-16544923
]
ASF subversion and git services commented on SOLR-11986:
Commit 1e50030940c2b089542e180d1abc6af66ac0c947 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e50030 ]
SOLR-12495,SOLR-11986 ref guide
> Allow percentage in freedisk attribute in autoscaling policy rules
> --
>
> Key: SOLR-11986
> URL: https://issues.apache.org/jira/browse/SOLR-11986
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.5
>
>
> We should allow users to specify freedisk as a percentage in addition to
> absolute values.
> For example, the following restricts adding any replicas on a node having
> freedisk less than 30% of total usable space.
> {code}
> {"replica" : 0, "freedisk" : "<30%"}
> {code}
--
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
[jira] [Commented] (SOLR-12495) Enhance the Autoscaling policy syntax to evenly distribute replicas among nodes
[
https://issues.apache.org/jira/browse/SOLR-12495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544922#comment-16544922
]
ASF subversion and git services commented on SOLR-12495:
Commit 1e50030940c2b089542e180d1abc6af66ac0c947 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e50030 ]
SOLR-12495,SOLR-11986 ref guide
> Enhance the Autoscaling policy syntax to evenly distribute replicas among
> nodes
> ---
>
> Key: SOLR-12495
> URL: https://issues.apache.org/jira/browse/SOLR-12495
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> Support a new function value for {{replica= "#EQUAL"}}
> {{#EQUAL}} means the equal no:of replicas on each {{"node"}}
> the value of replica will be calculated as {{<=
> Math.ceil(number_of_replicas/number_of_valid_nodes) }}
> *example 1:*
> {code:java}
> {"replica" : "#EQUAL" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *case 1* : nodes=3, replicationFactor=4
> the value of replica will be calculated as {{Math.ceil(4/3) = 1.33}}
> current state : nodes=3, replicationFactor=2
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "<3" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *case 2* :
> current state : nodes=3, replicationFactor=2
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "<3" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *example:2*
> {code}
> {"replica" : "#EQUAL" , "node" : "#ANY"}{code}
> *case 1*: numShards = 2, replicationFactor=3, nodes = 5
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "1.2" , "node" : "#ANY"}
> {code}
--
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
[jira] [Commented] (SOLR-12495) Enhance the Autoscaling policy syntax to evenly distribute replicas among nodes
[
https://issues.apache.org/jira/browse/SOLR-12495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544919#comment-16544919
]
ASF subversion and git services commented on SOLR-12495:
Commit 4240402c5e3b5c8d3c3882c0f813d896f9ec9fd0 in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4240402 ]
SOLR-12495,SOLR-11986 ref guide
> Enhance the Autoscaling policy syntax to evenly distribute replicas among
> nodes
> ---
>
> Key: SOLR-12495
> URL: https://issues.apache.org/jira/browse/SOLR-12495
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> Support a new function value for {{replica= "#EQUAL"}}
> {{#EQUAL}} means the equal no:of replicas on each {{"node"}}
> the value of replica will be calculated as {{<=
> Math.ceil(number_of_replicas/number_of_valid_nodes) }}
> *example 1:*
> {code:java}
> {"replica" : "#EQUAL" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *case 1* : nodes=3, replicationFactor=4
> the value of replica will be calculated as {{Math.ceil(4/3) = 1.33}}
> current state : nodes=3, replicationFactor=2
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "<3" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *case 2* :
> current state : nodes=3, replicationFactor=2
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "<3" , "shard" : "#EACH" , "node" : "#ANY"}
> {code}
> *example:2*
> {code}
> {"replica" : "#EQUAL" , "node" : "#ANY"}{code}
> *case 1*: numShards = 2, replicationFactor=3, nodes = 5
> this is equivalent to the hard coded rule
> {code:java}
> {"replica" : "1.2" , "node" : "#ANY"}
> {code}
--
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
[jira] [Commented] (SOLR-11986) Allow percentage in freedisk attribute in autoscaling policy rules
[
https://issues.apache.org/jira/browse/SOLR-11986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544921#comment-16544921
]
ASF subversion and git services commented on SOLR-11986:
Commit 4240402c5e3b5c8d3c3882c0f813d896f9ec9fd0 in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4240402 ]
SOLR-12495,SOLR-11986 ref guide
> Allow percentage in freedisk attribute in autoscaling policy rules
> --
>
> Key: SOLR-11986
> URL: https://issues.apache.org/jira/browse/SOLR-11986
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.5
>
>
> We should allow users to specify freedisk as a percentage in addition to
> absolute values.
> For example, the following restricts adding any replicas on a node having
> freedisk less than 30% of total usable space.
> {code}
> {"replica" : 0, "freedisk" : "<30%"}
> {code}
--
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
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 22461 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22461/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild Error Message: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException Stack Trace: java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: Unexpected wrapped exception type, expected CoreIsClosedException at __randomizedtesting.SeedInfo.seed([5389734890D56900:8C0411F7AEBC3C62]:0) at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: junit.framework.AssertionFailedError: Unexpected wrapped
[jira] [Created] (SOLR-12554) Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param
Ishan Chattopadhyaya created SOLR-12554: --- Summary: Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param Key: SOLR-12554 URL: https://issues.apache.org/jira/browse/SOLR-12554 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya Assignee: Ishan Chattopadhyaya Currently, the RAMPerThreadHardLimitMB parameter of IWC is not exposed. This is useful to control flush policies. -- 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
[jira] [Commented] (SOLR-11986) Allow percentage in freedisk attribute in autoscaling policy rules
[
https://issues.apache.org/jira/browse/SOLR-11986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544904#comment-16544904
]
ASF subversion and git services commented on SOLR-11986:
Commit 30eca8a87bf54330f87abf0eed197dcc10fb8409 in lucene-solr's branch
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=30eca8a ]
SOLR-11986: Allow percentage in freedisk attribute in autoscaling policy rules
> Allow percentage in freedisk attribute in autoscaling policy rules
> --
>
> Key: SOLR-11986
> URL: https://issues.apache.org/jira/browse/SOLR-11986
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.5
>
>
> We should allow users to specify freedisk as a percentage in addition to
> absolute values.
> For example, the following restricts adding any replicas on a node having
> freedisk less than 30% of total usable space.
> {code}
> {"replica" : 0, "freedisk" : "<30%"}
> {code}
--
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
[jira] [Commented] (SOLR-11986) Allow percentage in freedisk attribute in autoscaling policy rules
[
https://issues.apache.org/jira/browse/SOLR-11986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544902#comment-16544902
]
ASF subversion and git services commented on SOLR-11986:
Commit 11b22b441a70e69779e9aad7c355e24c6efc4a2f in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=11b22b4 ]
SOLR-11986: Allow percentage in freedisk attribute in autoscaling policy rules
> Allow percentage in freedisk attribute in autoscaling policy rules
> --
>
> Key: SOLR-11986
> URL: https://issues.apache.org/jira/browse/SOLR-11986
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.5
>
>
> We should allow users to specify freedisk as a percentage in addition to
> absolute values.
> For example, the following restricts adding any replicas on a node having
> freedisk less than 30% of total usable space.
> {code}
> {"replica" : 0, "freedisk" : "<30%"}
> {code}
--
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
[jira] [Assigned] (SOLR-11986) Allow percentage in freedisk attribute in autoscaling policy rules
[
https://issues.apache.org/jira/browse/SOLR-11986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-11986:
-
Assignee: Noble Paul
> Allow percentage in freedisk attribute in autoscaling policy rules
> --
>
> Key: SOLR-11986
> URL: https://issues.apache.org/jira/browse/SOLR-11986
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.5
>
>
> We should allow users to specify freedisk as a percentage in addition to
> absolute values.
> For example, the following restricts adding any replicas on a node having
> freedisk less than 30% of total usable space.
> {code}
> {"replica" : 0, "freedisk" : "<30%"}
> {code}
--
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
