[JENKINS] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk1.8.0_162) - Build # 22 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/22/ Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 7 tests failed. FAILED: org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: Path not found: response/docs/[12]/llp_1_dv_dvasst Stack Trace: java.lang.RuntimeException: Path not found: response/docs/[12]/llp_1_dv_dvasst at __randomizedtesting.SeedInfo.seed([57470EBD8365D8BD:71B364418FC29EF3]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1004) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:951) at org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval(TestSolr4Spatial2.java:226) 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.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: Path not found: response/docs/[21]/llp_1_dv_dvasst Stack Trace: java.lang.RuntimeException: Path not f
[jira] [Commented] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed
[
https://issues.apache.org/jira/browse/SOLR-12187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438241#comment-16438241
]
Lucene/Solr QA commented on SOLR-12187:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
12s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 3m 18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 3m 18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 3m 18s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 86m 4s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 95m 46s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.ZkControllerTest |
| | solr.search.TestSolr4Spatial2 |
| | solr.handler.admin.AutoscalingHistoryHandlerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12187 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918690/SOLR-12187.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 93f9a65 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_152 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/51/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/51/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/51/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch,
> SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in
> the number of issues related to the race condition between delete a replica
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica,
> therefore, forcefully remove its entry from clusterstate, but the replica
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
> * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to
> replica because the node is not live)
> * The node start and the replica get loaded
> * DELETECOREOP has not processed hence the replica still present in
> clusterstate --> pass checkStateInZk
> * DELETECOREOP is executed, DeleteReplicaCmd finished
> ** result 1: the replica start recovering, finish it and publish itself as
> ACTIVE --> state of the replica is ACTIVE
> ** result 2: the replica throw an exception (probably: NPE)
> --> state of the replica is DOWN, not join leader election
--
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/jdk1.8.0_144) - Build # 547 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/547/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC 13 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: found:2[index.20180413204137241, index.20180413204137738, index.properties, replication.properties, snapshot_metadata] Stack Trace: java.lang.AssertionError: found:2[index.20180413204137241, index.20180413204137738, index.properties, replication.properties, snapshot_metadata] at __randomizedtesting.SeedInfo.seed([B195D0EE296128C5:6A3ED0282C494176]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:968) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:939) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:915) 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.rand
[JENKINS] Lucene-Solr-BadApples-master-Linux (32bit/jdk1.8.0_162) - Build # 22 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/22/ Java: 32bit/jdk1.8.0_162 -server -XX:+UseParallelGC 7 tests failed. FAILED: org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:45405/solr/MoveReplicaHDFSTest_failed_coll_true, http://127.0.0.1:38317/solr/MoveReplicaHDFSTest_failed_coll_true] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:45405/solr/MoveReplicaHDFSTest_failed_coll_true, http://127.0.0.1:38317/solr/MoveReplicaHDFSTest_failed_coll_true] at __randomizedtesting.SeedInfo.seed([985392D38082195A:329E41213751CC8A]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:993) 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.client.solrj.SolrClient.query(SolrClient.java:942) at org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:310) 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(TestRule
[JENKINS] Lucene-Solr-repro - Build # 485 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/485/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1528/consoleText [repro] Revision: 376f6c494671ed22034bf56e6005e50b06942f28 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=NodeAddedTriggerTest -Dtests.method=testRestoreState -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=et-EE -Dtests.timezone=America/St_Thomas -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=BlockDirectoryTest -Dtests.method=testRandomAccessWritesLargeCache -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=ca -Dtests.timezone=Europe/Podgorica -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=LIROnShardRestartTest -Dtests.method=testAllReplicasInLIR -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=es-SV -Dtests.timezone=America/Bahia_Banderas -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=SaslZkACLProviderTest -Dtests.method=testSaslZkACLProvider -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=ar-LY -Dtests.timezone=Etc/GMT+7 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=SaslZkACLProviderTest -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=ar-LY -Dtests.timezone=Etc/GMT+7 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest -Dtests.method=test -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=be -Dtests.timezone=America/El_Salvador -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=ChaosMonkeyNothingIsSafeTest -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=be -Dtests.timezone=America/El_Salvador -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 93f9a65b1c8aa460489fdce50ed84d18168b53ef [repro] git fetch [repro] git checkout 376f6c494671ed22034bf56e6005e50b06942f28 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] NodeAddedTriggerTest [repro] BlockDirectoryTest [repro] ChaosMonkeyNothingIsSafeTest [repro] SaslZkACLProviderTest [repro] LIROnShardRestartTest [repro] ant compile-test [...truncated 3294 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=25 -Dtests.class="*.NodeAddedTriggerTest|*.BlockDirectoryTest|*.ChaosMonkeyNothingIsSafeTest|*.SaslZkACLProviderTest|*.LIROnShardRestartTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.seed=28A40EFF3C7A8E3E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=et-EE -Dtests.timezone=America/St_Thomas -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 5138 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest [repro] 0/5 failed: org.apache.solr.cloud.LIROnShardRestartTest [repro] 0/5 failed: org.apache.solr.cloud.autoscaling.No
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_144) - Build # 7270 - Still Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - 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 # 1529 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1529/
2 tests failed.
FAILED:
org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin
Error Message:
expected:<0> but was:<2>
Stack Trace:
java.lang.AssertionError: expected:<0> but was:<2>
at
__randomizedtesting.SeedInfo.seed([48DC3461D0EC401D:F20E5B1953C2AE08]: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.handler.dataimport.TestContentStreamDataSource.testCommitWithin(TestContentStreamDataSource.java:98)
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.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
Error Message:
expected:<[{indexVersion=152367080
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 1712 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1712/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseG1GC 7 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.request.TestUnInvertedFieldException Error Message: ObjectTracker found 5 object(s) that were not released!!! [MockDirectoryWrapper, MockDirectoryWrapper, SolrIndexSearcher, MockDirectoryWrapper, SolrCore] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:95) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:762) at org.apache.solr.core.SolrCore.(SolrCore.java:955) at org.apache.solr.core.SolrCore.(SolrCore.java:864) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1047) at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:643) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base/java.lang.Thread.run(Thread.java:844) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:499) at org.apache.solr.core.SolrCore.(SolrCore.java:949) at org.apache.solr.core.SolrCore.(SolrCore.java:864) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1047) at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:643) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base/java.lang.Thread.run(Thread.java:844) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.search.SolrIndexSearcher at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.search.SolrIndexSearcher.(SolrIndexSearcher.java:325) at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2047) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2220) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1957) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:719) at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:93) at org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:68) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1924) at org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1900) at org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:160) at org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:281) at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:188) at org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2508) at org.apache.solr.servlet.DirectSolrConnection.request(DirectSolrConnection.java:125) at org.apache.solr.util.TestHarness.update(TestHarness.java:284) at org.apache.solr.util.BaseTestHarness.checkUpdateStatus(BaseTestHarness.java:281) at org.apache.solr.util.BaseTestHarness.validateUpdate(BaseTestHarness.java:251) at org.apache.solr.SolrTestCaseJ4.checkUpdateU(SolrTestCaseJ4.java:863) at org.apache.solr.SolrTestCaseJ4.assertU(SolrTestCaseJ4.java:84
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 559 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/559/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 6 tests failed. FAILED: org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: Path not found: response/docs/[12]/llp_1_dv_dvasst Stack Trace: java.lang.RuntimeException: Path not found: response/docs/[12]/llp_1_dv_dvasst at __randomizedtesting.SeedInfo.seed([954FAED98FE61E23:B3BBC4258341586D]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1004) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:951) at org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval(TestSolr4Spatial2.java:226) 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.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: mismatch: '40.2996544,-74.0824957'!='40.29965431,-74.08249572' @ response/docs/[3]/llp_1_dv_dvasst Stack Trace:
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+5) - Build # 21820 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21820/ Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: mismatch: '40.2996544,-74.0824957'!='40.29965431,-74.08249572' @ response/docs/[3]/llp_1_dv_dvasst Stack Trace: java.lang.RuntimeException: mismatch: '40.2996544,-74.0824957'!='40.29965431,-74.08249572' @ response/docs/[3]/llp_1_dv_dvasst at __randomizedtesting.SeedInfo.seed([9CF5667905AB158E:BA010C85090C53C0]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1004) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:951) at org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval(TestSolr4Spatial2.java:226) 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:841) FAILED: org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: Path not found: response/docs/[12]/l
[jira] [Commented] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438181#comment-16438181
]
Boris Pasko commented on SOLR-6305:
---
Looks like when recovery is performed, the index is downloaded by some code
that still uses server-side replication factor.
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Priority: Major
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent
> directory.
> Not sure if we need to go as far as allowing different replication factor per
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through
> this using the Configuration object but nothing jumped out at me ... and the
> implementation for getServerDefaults(path) is just:
> public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
> }
> Path is ignored ;-)
--
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-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438178#comment-16438178
]
Boris Pasko commented on SOLR-6305:
---
Unfortunately, it seems that the patch I did does not cover all usecases. It
might be that merging is still done with server-side replication factor:
{noformat}
$ hadoop fs -du -h /solr/classified/core_node4/data70.0 G 209.9 G
/solr/classified/core_node4/data/index.20180411213103577
70.0 G 209.9 G /solr/classified/core_node4/data/index.20180411213103577
78 78 /solr/classified/core_node4/data/index.properties
210 210 /solr/classified/core_node4/data/replication.properties
00/solr/classified/core_node4/data/snapshot_metadata
915.3 M 1.8 G/solr/classified/core_node4/data/tlog
{noformat}
and
{noformat}
$ hadoop fs -ls /solr/classified/core_node2/data/index
-rwxr-xr-x 1 solr solr418 2018-04-13 21:25
/solr/classified/core_node2/data/index/_13ke.si
-rwxr-xr-x 3 solr solr 663715968 2018-04-11 17:22
/solr/classified/core_node2/data/index/_3fp.fdt
-rwxr-xr-x 3 solr solr 517308 2018-04-11 17:21
/solr/classified/core_node2/data/index/_3fp.fdx
-rwxr-xr-x 3 solr solr 3638 2018-04-11 17:21
/solr/classified/core_node2/data/index/_3fp.fnm
-rwxr-xr-x 3 solr solr 25644767 2018-04-11 17:21
/solr/classified/core_node2/data/index/_3fp.nvd
-rwxr-xr-x 3 solr solr178 2018-04-11 17:21
/solr/classified/core_node2/data/index/_3fp.nvm
-rwxr-xr-x 3 solr solr522 2018-04-11 17:22
/solr/classified/core_node2/data/index/_3fp.si
-rwxr-xr-x 1 solr solr 356244 2018-04-12 08:14
/solr/classified/core_node2/data/index/_3fp_9v.liv
-rwxr-xr-x 3 solr solr 1634072760 2018-04-11 17:21
/solr/classified/core_node2/data/index/_3fp_Lucene50_0.doc
-rwxr-xr-x 3 solr solr 2698137408 2018-04-11 17:22
/solr/classified/core_node2/data/index/_3fp_Lucene50_0.pos
-rwxr-xr-x 3 solr solr 365912676 2018-04-11 17:21
/solr/classified/core_node2/data/index/_3fp_Lucene50_0.tim
-rwxr-xr-x 3 solr solr6024240 2018-04-11 17:21
/solr/classified/core_node2/data/index/_3fp_Lucene50_0.tip
-rwxr-xr-x 3 solr solr 596163565 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi.fdt
-rwxr-xr-x 3 solr solr 479765 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi.fdx
-rwxr-xr-x 3 solr solr 3638 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi.fnm
-rwxr-xr-x 3 solr solr 26688139 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi.nvd
-rwxr-xr-x 3 solr solr178 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi.nvm
-rwxr-xr-x 3 solr solr522 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi.si
-rwxr-xr-x 3 solr solr 1466093502 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi_Lucene50_0.doc
-rwxr-xr-x 3 solr solr 2374256964 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi_Lucene50_0.pos
-rwxr-xr-x 3 solr solr 345128291 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi_Lucene50_0.tim
-rwxr-xr-x 3 solr solr5839414 2018-04-11 17:22
/solr/classified/core_node2/data/index/_5oi_Lucene50_0.tip
-rwxr-xr-x 1 solr solr 333668 2018-04-12 04:11
/solr/classified/core_node2/data/index/_5oi_aj.liv
{noformat}
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Priority: Major
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/in
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1801 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1801/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 6 tests failed. FAILED: org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: mismatch: '-90,180'!='-90,179.9992' @ response/docs/[6]/llp_N_dv_dvasst/[0] Stack Trace: java.lang.RuntimeException: mismatch: '-90,180'!='-90,179.9992' @ response/docs/[6]/llp_N_dv_dvasst/[0] at __randomizedtesting.SeedInfo.seed([95B4EFAFC7E1CEA2:B3408553CB4688EC]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1004) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:951) at org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval(TestSolr4Spatial2.java:226) 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.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: Path not found: response/docs/[15]/llp_N_dv_dvasst
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 1711 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1711/ Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseParallelGC 5 tests failed. FAILED: org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: mismatch: '-40,40'!='-40,39.9997' @ response/docs/[5]/llp_N_dv_dvasst/[0] Stack Trace: java.lang.RuntimeException: mismatch: '-40,40'!='-40,39.9997' @ response/docs/[5]/llp_N_dv_dvasst/[0] at __randomizedtesting.SeedInfo.seed([1ABFCCC32F678305:3C4BA63F23C0C54B]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:1004) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:951) at org.apache.solr.search.TestSolr4Spatial2.testLatLonRetrieval(TestSolr4Spatial2.java:226) 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.search.TestSolr4Spatial2.testLatLonRetrieval Error Message: Path not found: response/docs/[14]/llp_N_dv_dvasst Stack Trace: java.lang.RuntimeException: P
Re: [jira] [Commented] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
yes, thanks! On Fri, Apr 13, 2018 at 7:05 PM, Michael McCandless (JIRA) wrote: > > [ https://issues.apache.org/jira/browse/LUCENE-8248?page= > com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=16438060#comment-16438060 ] > > Michael McCandless commented on LUCENE-8248: > > > Woops, thanks [~varunthacker]! > > > Rename MergePolicyWrapper to FilterMergePolicy and override all of > MergePolicy > > > -- > > > > Key: LUCENE-8248 > > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > > Project: Lucene - Core > > Issue Type: Wish > > Components: core/index > >Reporter: Mike Sokolov > >Priority: Minor > > Fix For: 7.4, master (8.0) > > > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding > setter is not, which means that overriding it with anything other than a > trivial delegation can only lead to confusion. > > The patch makes the method final and removes the trivial implementations > from MergePolicyWrapper and NoMergePolicy. > > [~mikemccand] also pointed out that the class name is nonstandard for > similar adapter classes in Lucene, which are usually Filter*.java. > Personally I was looking for MergePolicyAdapter, but if there is a > prevailing convention here around Filter, does it make sense to change this > class's name to FilterMergePolicy? > > > > -- > 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-12137) Create Windows-equivalent of bin-test/test
[
https://issues.apache.org/jira/browse/SOLR-12137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-12137:
---
Description:
SOLR-11749 introduced a regression suite for the {{bin/solr}} scripts.
Currently this suite (located in {{solr/bin-test}} only covers the *nix copy of
{{bin/solr}}. No tests are run for the Windows version.
This JIRA involves porting the existing {{bin-test/test}} logic (along with the
accompanying tests) to Windows batch. This will allow both versions of the
script to be tested, and will open the door to future steps, like hooking the
suite into one of ant's test targets.
was:
SOLR-11749 introduced a regression suite for the {{bin/solr}} scripts.
Currently this suite (located in {{solr/bin-test}} only covers the *nix copy of
{{bin/solr}}. No tests are run for the Windows version.
This JIRA involves porting the existing {{bin-test/test}} logic (along with the
accompanying tests) to Windows batch. This will allow both version of the
script to be tested.
> Create Windows-equivalent of bin-test/test
> --
>
> Key: SOLR-12137
> URL: https://issues.apache.org/jira/browse/SOLR-12137
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
>
> SOLR-11749 introduced a regression suite for the {{bin/solr}} scripts.
> Currently this suite (located in {{solr/bin-test}} only covers the *nix copy
> of {{bin/solr}}. No tests are run for the Windows version.
> This JIRA involves porting the existing {{bin-test/test}} logic (along with
> the accompanying tests) to Windows batch. This will allow both versions of
> the script to be tested, and will open the door to future steps, like hooking
> the suite into one of ant's test targets.
--
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-12222) TestDistributedSearch failure: "Expected to find shardAddress in the up shard info"
[
https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438078#comment-16438078
]
Tomás Fernández Löbbe commented on SOLR-1:
--
This seems to be the cases where the "time allowed" is checked inside
{{LBHttpSolrClient.request}}. I think we can just correct the test. See patch
attached.
> TestDistributedSearch failure: "Expected to find shardAddress in the up shard
> info"
> ---
>
> Key: SOLR-1
> URL: https://issues.apache.org/jira/browse/SOLR-1
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-1.patch
>
>
> This is a pretty common failure of this test. Here is an example from a
> recent Jenkins failure
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1630/
> Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseParallelGC
> 1 tests failed.
> FAILED: org.apache.solr.TestDistributedSearch.test
> Error Message:
> Expected to find shardAddress in the up shard info:
> {error=org.apache.solr.client.solrj.SolrServerException: Time allowed to
> handle this request
> exceeded,trace=org.apache.solr.client.solrj.SolrServerException: Time allowed
> to handle this request exceeded at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
> at
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
> 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) ,time=1}
> Stack Trace:
> java.lang.AssertionError: Expected to find shardAddress in the up shard info:
> {error=org.apache.solr.client.solrj.SolrServerException: Time allowed to
> handle this request
> exceeded,trace=org.apache.solr.client.solrj.SolrServerException: Time allowed
> to handle this request exceeded
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
> at
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12222) TestDistributedSearch failure: "Expected to find shardAddress in the up shard info"
[
https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-1:
-
Attachment: SOLR-1.patch
> TestDistributedSearch failure: "Expected to find shardAddress in the up shard
> info"
> ---
>
> Key: SOLR-1
> URL: https://issues.apache.org/jira/browse/SOLR-1
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-1.patch
>
>
> This is a pretty common failure of this test. Here is an example from a
> recent Jenkins failure
> {noformat}
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1630/
> Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseParallelGC
> 1 tests failed.
> FAILED: org.apache.solr.TestDistributedSearch.test
> Error Message:
> Expected to find shardAddress in the up shard info:
> {error=org.apache.solr.client.solrj.SolrServerException: Time allowed to
> handle this request
> exceeded,trace=org.apache.solr.client.solrj.SolrServerException: Time allowed
> to handle this request exceeded at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
> at
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
> 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) ,time=1}
> Stack Trace:
> java.lang.AssertionError: Expected to find shardAddress in the up shard info:
> {error=org.apache.solr.client.solrj.SolrServerException: Time allowed to
> handle this request
> exceeded,trace=org.apache.solr.client.solrj.SolrServerException: Time allowed
> to handle this request exceeded
> at
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
> at
> org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12196) Prepare Admin UI for migrating to Angular.io
[ https://issues.apache.org/jira/browse/SOLR-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438072#comment-16438072 ] Alexandre Rafalovitch commented on SOLR-12196: -- My feeling is that "if not now" will be "close to never". Because it was a huge effort to move it to Angular 1 and some bits were not even finished for very long time (ever?). So, let's say another 3 years before anybody will raise this conversation with the same amount of "sunk costs" as right now. As to how/who, yeah, that's the big issue. Has been, it seems for a long time. I am interested in learning React but I am not a frontend dev myself to take a lead. And certainly not a visual designer, which is the hairy part... But my feeling is that maybe it is worth asking on the dev list as a tradeoff discussion. > Prepare Admin UI for migrating to Angular.io > > > Key: SOLR-12196 > URL: https://issues.apache.org/jira/browse/SOLR-12196 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Labels: Angular, AngularJS, angular-migration > Fix For: master (8.0) > > > AngularJS is soon end of life, it [enters LTS in july > 2018|https://docs.angularjs.org/misc/version-support-status], whereupon it > will only receive fixes to serious bugs. Solr uses AngularJS 1.3 (the latest > AngularJS will be 1.7). > This issue is *not* for upgrading to Angular5/6, but to start preparing the > existing UI for easier migration later on. See > [https://angular.io/guide/upgrade]. > This JIRA will likely get multiple sub tasks such as > * Change to [Folders-by-Feature > Structure|https://angular.io/guide/upgrade#follow-the-angularjs-style-guide], > i.e. mix html, css, js in a folder based on feature > * Use a [Module > Loader|https://angular.io/guide/upgrade#using-a-module-loader] like > [Webpack|https://webpack.js.org/] > * Use [Component > Directives|https://angular.io/guide/upgrade#using-component-directives] > (requires first move from AngularJS 1.3 to 1.5) > The rationale for this lira is recognising how central the Admin UI is to > Solr, not letting it rot on top of a dying framework. Better to start moving > step by step and [perhaps write all new views in Angular > 5|https://angular.io/guide/upgrade#upgrading-with-ngupgrade], than to fall > further and further behind. > This effort of course assumes that Angular.io is the path we want to go, and > not React, VueJS or some other new kid on the block :) -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438060#comment-16438060 ] Michael McCandless commented on LUCENE-8248: Woops, thanks [~varunthacker]! > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438043#comment-16438043 ] ASF subversion and git services commented on LUCENE-8248: - Commit a035d8e01c94a4592d427bf0d71faa941ab4e983 in lucene-solr's branch refs/heads/branch_7x from [~varun_saxena] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a035d8e ] LUCENE-8248: Remove unused import > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-7736) Add a test for ZkController.publishAndWaitForDownStates
[
https://issues.apache.org/jira/browse/SOLR-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438035#comment-16438035
]
Tomás Fernández Löbbe commented on SOLR-7736:
-
I think we should just return in this particular case. No need to continue
processing in that particular case (the {{updateLock.lockInterruptibly();}}
will generate another InterruptedException that will be logged (again) and
break the while, but no need to wait for that I think.
While looking at this particular class I noticed that other things my throw
InterruptedExceptions that we are just swallowing, like:
{code:java}
scheduledTriggers.add(entry.getValue());{code}
or
{code:java}
List markers =
stateManager.listData(ZkStateReader.SOLR_AUTOSCALING_NODE_LOST_PATH);{code}
this throws {{Exception}} and we catch and log it, but that exception could
actually be an {{InterruptedException}}. Maybe we should change some of those
methods to throw exception types more specific than {{Exception}} (Including
{{InterruptedException}}), that way it will be harder to miss it
> Add a test for ZkController.publishAndWaitForDownStates
> ---
>
> Key: SOLR-7736
> URL: https://issues.apache.org/jira/browse/SOLR-7736
> Project: Solr
> Issue Type: Test
> Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-7736.patch, SOLR-7736.patch,
> ZkController.failure.txt, consoleFull-2462-ZkControllerTest.txt.gz
>
>
> Add a test for ZkController.publishAndWaitForDownStates so that bugs like
> SOLR-6665 do not occur again. A test exists but it is not correct and
> currently disabled via AwaitsFix.
--
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 # 21819 - Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438031#comment-16438031 ] Varun Thacker commented on LUCENE-8248: --- I'll fix the precommit issue by removing the unused import in a few mins > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438032#comment-16438032 ] ASF subversion and git services commented on SOLR-11724: Commit b0c095c1804149bf558064d7f7df76f318a5c5ee in lucene-solr's branch refs/heads/branch_7x from [~varun_saxena] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b0c095c ] SOLR-11724: Cdcr bootstrapping should ensure that non-leader replicas should sync with the leader (cherry picked from commit 93f9a65) > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Affects Versions: 7.1 >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Attachments: SOLR-11724.patch, SOLR-11724.patch > > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- 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-12120) New plugin type AuditLoggerPlugin
[
https://issues.apache.org/jira/browse/SOLR-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438027#comment-16438027
]
Jan Høydahl commented on SOLR-12120:
I also added a new EventType {{COMPLETED}} which is logged when a search is
completed (or failed).
Agree that what types you want to log will vary. We could leave it up to
concrete implementations, but probably the framework should aid with some
configuration options that makes it possible to log only some types, or to
avoid firing AUTHENTICATED event if the call continues etc.
I've also added support for multiple loggers being called in a chain. So far
that is done with a MultiLogger impl that takes a list of other loggers in the
config. But I wonder if perhaps we should also support a JSON array notation
natively?:
{code:javascript}
"auditlogging" : [
{ "class" : "solr.Audit1", ... },
{ "class" : "solr.Audit2", ... }
]
{code}
> New plugin type AuditLoggerPlugin
> -
>
> Key: SOLR-12120
> URL: https://issues.apache.org/jira/browse/SOLR-12120
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Solr needs a well defined plugin point to implement audit logging
> functionality, which is independent from whatever {{AuthenticationPlugin}} or
> {{AuthorizationPlugin}} are in use at the time.
> It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It
> could be configured in solr.xml or it could be a third type of plugin defined
> in {{security.json}}, i.e.
> {code:java}
> {
> "authentication" : { "class" : ... },
> "authorization" : { "class" : ... },
> "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
> }
> {code}
> We could then instrument SolrDispatchFilter to the audit plugin with an
> AuditEvent at important points such as successful authentication:
> {code:java}
> auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED,
> request));
> {code}
> We will mark the impl as {{@lucene.experimental}} in the first release to
> let it settle as people write their own plugin implementations.
--
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-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438022#comment-16438022 ] ASF subversion and git services commented on SOLR-11724: Commit 93f9a65b1c8aa460489fdce50ed84d18168b53ef in lucene-solr's branch refs/heads/master from [~varun_saxena] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=93f9a65 ] SOLR-11724: Cdcr bootstrapping should ensure that non-leader replicas should sync with the leader > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Affects Versions: 7.1 >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Attachments: SOLR-11724.patch, SOLR-11724.patch > > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- 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-MacOSX (64bit/jdk1.8.0) - Build # 577 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/577/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 52062 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir:
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1994864991
[ecj-lint] Compiling 838 source files to
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1994864991
[ecj-lint] --
[ecj-lint] 1. WARNING in
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/core/src/java/org/apache/lucene/codecs/CodecUtil.java
(at line 523)
[ecj-lint] throw new CorruptIndexException("misplaced codec footer (file
truncated?): length=" + in.length() + " but footerLength==" + footerLength(),
input);
[ecj-lint]
^^^
[ecj-lint] Resource leak: 'in' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. ERROR in
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/core/src/java/org/apache/lucene/index/MergePolicyWrapper.java
(at line 19)
[ecj-lint] import java.io.IOException;
[ecj-lint]^^^
[ecj-lint] The import java.io.IOException is never used
[ecj-lint] --
[ecj-lint] 3. ERROR in
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/core/src/java/org/apache/lucene/index/MergePolicyWrapper.java
(at line 21)
[ecj-lint] import org.apache.lucene.util.IOSupplier;
[ecj-lint]^
[ecj-lint] The import org.apache.lucene.util.IOSupplier is never used
[ecj-lint] --
[ecj-lint] 3 problems (2 errors, 1 warning)
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:633: The following
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/build.xml:101: The following
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build.xml:203: The
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2089:
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/common-build.xml:2128:
Compile failed; see the compiler error output for details.
Total time: 101 minutes 6 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: InterruptedException handling between solr->zk interactions
Yes, I've seen these issues too. The right thing to do is to close all resources (in some cases finish anything that can't be left in a bad state) and exit. In this particular case I'd think the InterruptedException is swallowed unintentionally because of the catch (Exception ). I suspect for the OverseerTaskProcessor the right thing to do is to close and exit?. We should at the very least be restoring the interrupted flag (so that Mikhail's fix would make the thread exit immediately) On Fri, Apr 13, 2018 at 3:02 PM, Mikhail Khludnev wrote: > Hello, Varun. > > If you are bothered with > --- Thousands of "Session expired for /autoscaling.json" messages before I > had to manually kill the test run > it should be resolved by > https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a= > commitdiff;h=a4789db > > > On Sat, Apr 14, 2018 at 12:31 AM, Varun Thacker wrote: > >> Is there a general strategy on how to deal with InterruptedException >> while issues a zookeeper call from solr? >> >> Here's a more concrete example which I am unsure if it's doing the right >> thing or not: >> >> https://github.com/apache/lucene-solr/blob/master/solr/core/ >> src/java/org/apache/solr/cloud/OverseerTaskProcessor.java#L180 >> >> This code simply catches Exception. So if InterruptedException is thrown >> , we simply log an ERROR and move on. >> >> Excerpt logs from a local failed test run: https://gist.github.com/v >> thacker/5dcb8978ba177d8725e98c5d433ee6c2 >> >> > > > -- > Sincerely yours > Mikhail Khludnev >
[jira] [Commented] (SOLR-7736) Add a test for ZkController.publishAndWaitForDownStates
[
https://issues.apache.org/jira/browse/SOLR-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438007#comment-16438007
]
Varun Thacker commented on SOLR-7736:
-
{code:java}
log.warn("Interrupted");{code}
Should we make this a little more descriptive : like "Exiting
OverseerTriggerThread" ?
Should we break when we catch this InterruptedException?
{code:java}
try {
refreshAutoScalingConf(new AutoScalingWatcher());
} catch (ConnectException e) {
log.warn("ZooKeeper watch triggered for autoscaling conf, but Solr cannot
talk to ZK: [{}]", e.getMessage());
} catch (InterruptedException e) {
// Restore the interrupted status
Thread.currentThread().interrupt();
log.warn("Interrupted", e);
}{code}
> Add a test for ZkController.publishAndWaitForDownStates
> ---
>
> Key: SOLR-7736
> URL: https://issues.apache.org/jira/browse/SOLR-7736
> Project: Solr
> Issue Type: Test
> Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-7736.patch, SOLR-7736.patch,
> ZkController.failure.txt, consoleFull-2462-ZkControllerTest.txt.gz
>
>
> Add a test for ZkController.publishAndWaitForDownStates so that bugs like
> SOLR-6665 do not occur again. A test exists but it is not correct and
> currently disabled via AwaitsFix.
--
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-12196) Prepare Admin UI for migrating to Angular.io
[ https://issues.apache.org/jira/browse/SOLR-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438005#comment-16438005 ] Jan Høydahl commented on SOLR-12196: It would be great with a re-imagined Admin and a brand new framework :) But as I wrote initially, are we rigged for such a huge job now? In my head it is more realistic with byte-size improvements as laid out in this Jira with the goal of getting to Angular5 (still much work but less than React?). Keep the same design. Even keep parts of the UI as-is using ngUpgrade? Then do visual and logical re-design step by step after that. If we have the will, skill and capacity to start from scratch with React and re-design then I won't vote against, but I don't see how/who? > Prepare Admin UI for migrating to Angular.io > > > Key: SOLR-12196 > URL: https://issues.apache.org/jira/browse/SOLR-12196 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Labels: Angular, AngularJS, angular-migration > Fix For: master (8.0) > > > AngularJS is soon end of life, it [enters LTS in july > 2018|https://docs.angularjs.org/misc/version-support-status], whereupon it > will only receive fixes to serious bugs. Solr uses AngularJS 1.3 (the latest > AngularJS will be 1.7). > This issue is *not* for upgrading to Angular5/6, but to start preparing the > existing UI for easier migration later on. See > [https://angular.io/guide/upgrade]. > This JIRA will likely get multiple sub tasks such as > * Change to [Folders-by-Feature > Structure|https://angular.io/guide/upgrade#follow-the-angularjs-style-guide], > i.e. mix html, css, js in a folder based on feature > * Use a [Module > Loader|https://angular.io/guide/upgrade#using-a-module-loader] like > [Webpack|https://webpack.js.org/] > * Use [Component > Directives|https://angular.io/guide/upgrade#using-component-directives] > (requires first move from AngularJS 1.3 to 1.5) > The rationale for this lira is recognising how central the Admin UI is to > Solr, not letting it rot on top of a dying framework. Better to start moving > step by step and [perhaps write all new views in Angular > 5|https://angular.io/guide/upgrade#upgrading-with-ngupgrade], than to fall > further and further behind. > This effort of course assumes that Angular.io is the path we want to go, and > not React, VueJS or some other new kid on the block :) -- 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
Re: InterruptedException handling between solr->zk interactions
Hi Mikhail, My checkout already has that commit when i ran into this issue. I'll reply on SOLR-7736 with some more details. On Fri, Apr 13, 2018 at 3:02 PM, Mikhail Khludnev wrote: > Hello, Varun. > > If you are bothered with > --- Thousands of "Session expired for /autoscaling.json" messages before I > had to manually kill the test run > it should be resolved by > https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a= > commitdiff;h=a4789db > > > On Sat, Apr 14, 2018 at 12:31 AM, Varun Thacker wrote: > >> Is there a general strategy on how to deal with InterruptedException >> while issues a zookeeper call from solr? >> >> Here's a more concrete example which I am unsure if it's doing the right >> thing or not: >> >> https://github.com/apache/lucene-solr/blob/master/solr/core/ >> src/java/org/apache/solr/cloud/OverseerTaskProcessor.java#L180 >> >> This code simply catches Exception. So if InterruptedException is thrown >> , we simply log an ERROR and move on. >> >> Excerpt logs from a local failed test run: https://gist.github.com/v >> thacker/5dcb8978ba177d8725e98c5d433ee6c2 >> >> > > > -- > Sincerely yours > Mikhail Khludnev >
Re: InterruptedException handling between solr->zk interactions
Hello, Varun. If you are bothered with --- Thousands of "Session expired for /autoscaling.json" messages before I had to manually kill the test run it should be resolved by https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=a4789db On Sat, Apr 14, 2018 at 12:31 AM, Varun Thacker wrote: > Is there a general strategy on how to deal with InterruptedException while > issues a zookeeper call from solr? > > Here's a more concrete example which I am unsure if it's doing the right > thing or not: > > https://github.com/apache/lucene-solr/blob/master/solr/ > core/src/java/org/apache/solr/cloud/OverseerTaskProcessor.java#L180 > > This code simply catches Exception. So if InterruptedException is thrown , > we simply log an ERROR and move on. > > Excerpt logs from a local failed test run: https://gist.github.com/ > vthacker/5dcb8978ba177d8725e98c5d433ee6c2 > > -- Sincerely yours Mikhail Khludnev
[jira] [Commented] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437977#comment-16437977 ] Mike Sokolov commented on LUCENE-8248: -- yw - thanks for submitting [~mikemccand] > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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
InterruptedException handling between solr->zk interactions
Is there a general strategy on how to deal with InterruptedException while issues a zookeeper call from solr? Here's a more concrete example which I am unsure if it's doing the right thing or not: https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/OverseerTaskProcessor.java#L180 This code simply catches Exception. So if InterruptedException is thrown , we simply log an ERROR and move on. Excerpt logs from a local failed test run: https://gist.github.com/vthacker/5dcb8978ba177d8725e98c5d433ee6c2
[jira] [Commented] (SOLR-5859) Harden the Overseer restart mechanism
[
https://issues.apache.org/jira/browse/SOLR-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437946#comment-16437946
]
Mikhail Khludnev commented on SOLR-5859:
[~noble.paul], I want to clarify
https://github.com/apache/lucene-solr/commit/3fd292234166105f96fcb5acd3999c9c2abff737#diff-9ed614eee66b9e685d73446b775dc043R287
{quote}
//do this in a separate thread because any wait is interrupted in this
main thread
new Thread(this::checkIfIamStillLeader, "OverseerExitThread").start();
{quote}
Can't we clean interrupt flag with {{Thread.interrupted()}} and avoid spawning
new thread ?
> Harden the Overseer restart mechanism
> -
>
> Key: SOLR-5859
> URL: https://issues.apache.org/jira/browse/SOLR-5859
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 4.8, 6.0
>
> Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch,
> SOLR-5859.patch
>
>
> SOLR-5476 depends on Overseer restart.The current strategy is to remove the
> zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and
> start the new overseer.
> Though overseer ops are short running, it is not a 100% foolproof strategy
> because if an operation takes longer than the wait period there can be race
> condition.
--
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] (SOLR-5859) Harden the Overseer restart mechanism
[
https://issues.apache.org/jira/browse/SOLR-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437946#comment-16437946
]
Mikhail Khludnev edited comment on SOLR-5859 at 4/13/18 9:23 PM:
-
[~noble.paul], I want to clarify
https://github.com/apache/lucene-solr/commit/3fd292234166105f96fcb5acd3999c9c2abff737#diff-9ed614eee66b9e685d73446b775dc043R287
{code}
//do this in a separate thread because any wait is interrupted in this
main thread
new Thread(this::checkIfIamStillLeader, "OverseerExitThread").start();
{code}
Can't we clean interrupt flag with {{Thread.interrupted()}} and avoid spawning
new thread ?
was (Author: mkhludnev):
[~noble.paul], I want to clarify
https://github.com/apache/lucene-solr/commit/3fd292234166105f96fcb5acd3999c9c2abff737#diff-9ed614eee66b9e685d73446b775dc043R287
{quote}
//do this in a separate thread because any wait is interrupted in this
main thread
new Thread(this::checkIfIamStillLeader, "OverseerExitThread").start();
{quote}
Can't we clean interrupt flag with {{Thread.interrupted()}} and avoid spawning
new thread ?
> Harden the Overseer restart mechanism
> -
>
> Key: SOLR-5859
> URL: https://issues.apache.org/jira/browse/SOLR-5859
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 4.8, 6.0
>
> Attachments: SOLR-5859.patch, SOLR-5859.patch, SOLR-5859.patch,
> SOLR-5859.patch
>
>
> SOLR-5476 depends on Overseer restart.The current strategy is to remove the
> zk node for leader election and wait for STATUS_UPDATE_DELAY +100 ms and
> start the new overseer.
> Though overseer ops are short running, it is not a 100% foolproof strategy
> because if an operation takes longer than the wait period there can be race
> condition.
--
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_162) - Build # 1710 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1710/ Java: 32bit/jdk1.8.0_162 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 15244 lines...] [junit4] JVM J2: stdout was not empty, see: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/temp/junit4-J2-20180413_201459_4458884734872072488303.sysout [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] java.lang.OutOfMemoryError: Java heap space [junit4] Dumping heap to /home/jenkins/workspace/Lucene-Solr-7.x-Linux/heapdumps/java_pid30627.hprof ... [junit4] Heap dump file created [444373316 bytes in 0.729 secs] [junit4] <<< JVM J2: EOF [...truncated 9432 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:633: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:585: Some of the tests produced a heap dump, but did not fail. Maybe a suppressed OutOfMemoryError? Dumps created: * java_pid30627.hprof Total time: 85 minutes 26 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 Setting ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11731) LatLonPointSpatialField could be improved to return the lat/lon from docValues
[ https://issues.apache.org/jira/browse/SOLR-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-11731. - Resolution: Fixed I spent more time looking at this and committed an improvement adding one more decimal place -- 8. This gets us to below the theoretical precision. The test now tests with the theoretical bounds (now even more aggressive -- 1.04cm down from 1.33cm). I looped it a few thousand times without failure. > LatLonPointSpatialField could be improved to return the lat/lon from docValues > -- > > Key: SOLR-11731 > URL: https://issues.apache.org/jira/browse/SOLR-11731 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: spatial >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.4 > > Attachments: SOLR-11731.patch, SOLR-11731.patch, SOLR-11731.patch > > Time Spent: 4.5h > Remaining Estimate: 0h > > You can only return the lat & lon from a LatLonPointSpatialField if you set > stored=true. But we could allow this (albeit at a small loss in precision) > if stored=false and docValues=true. -- 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-11731) LatLonPointSpatialField could be improved to return the lat/lon from docValues
[ https://issues.apache.org/jira/browse/SOLR-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437914#comment-16437914 ] ASF subversion and git services commented on SOLR-11731: Commit 6f693ce7f1d57ec8581bd37b1a9a3f3a2abb626d in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6f693ce ] SOLR-11731: one more decimal place (8) and we get the target/theoretical precision (cherry picked from commit e4eb8a8) > LatLonPointSpatialField could be improved to return the lat/lon from docValues > -- > > Key: SOLR-11731 > URL: https://issues.apache.org/jira/browse/SOLR-11731 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: spatial >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.4 > > Attachments: SOLR-11731.patch, SOLR-11731.patch, SOLR-11731.patch > > Time Spent: 4.5h > Remaining Estimate: 0h > > You can only return the lat & lon from a LatLonPointSpatialField if you set > stored=true. But we could allow this (albeit at a small loss in precision) > if stored=false and docValues=true. -- 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-11731) LatLonPointSpatialField could be improved to return the lat/lon from docValues
[ https://issues.apache.org/jira/browse/SOLR-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437912#comment-16437912 ] ASF subversion and git services commented on SOLR-11731: Commit e4eb8a870c342b49c8f0a0864d34617cac1deb0f in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e4eb8a8 ] SOLR-11731: one more decimal place (8) and we get the target/theoretical precision > LatLonPointSpatialField could be improved to return the lat/lon from docValues > -- > > Key: SOLR-11731 > URL: https://issues.apache.org/jira/browse/SOLR-11731 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: spatial >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.4 > > Attachments: SOLR-11731.patch, SOLR-11731.patch, SOLR-11731.patch > > Time Spent: 4.5h > Remaining Estimate: 0h > > You can only return the lat & lon from a LatLonPointSpatialField if you set > stored=true. But we could allow this (albeit at a small loss in precision) > if stored=false and docValues=true. -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437873#comment-16437873 ] ASF subversion and git services commented on LUCENE-8248: - Commit e2e89d1a608c1143db77c1e7175672e4fa19ea3e in lucene-solr's branch refs/heads/master from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e2e89d1 ] LUCENE-8248: remove deprecated MergePolicyWrapper for 8.x > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437864#comment-16437864 ] ASF subversion and git services commented on LUCENE-8248: - Commit ffa1bf7a0a206dd2fbdf4a1ad68b8f00f250a20f in lucene-solr's branch refs/heads/branch_7x from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ffa1bf7 ] LUCENE-8248: remove duplicate method; fix test to reference FilterMergePolicy > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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
Re: Precommit failures
Requirements for javadocs vary between Lucene and Solr (and between packages) as far as I understand it. https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.0/lucene/build.xml#L156-L199 is for Lucene and there is a semi-equivalent at https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.0/solr/build.xml#L678 for Solr. Christine From: dev@lucene.apache.org At: 04/13/18 03:56:17To: dev@lucene.apache.org Subject: Re: Precommit failures It's happening to me too! I added a /** anything */ comment on these two methods and the warning went away. But we don't have rules about requiring comments on public methods (I thought)? On Thu, Apr 12, 2018 at 8:51 PM Erick Erickson wrote: I'm getting this precommit failure on a fresh clone of master: -documentation-lint: [echo] checking for broken html... [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /Users/Erick/apache/solrVersions/solr-12028/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for missing docs... [exec] [exec] build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html [exec] missing Methods: strictlyWithin-double-double-double- [exec] missing Methods: strictlyWithin-org.apache.lucene.spatial3d.geom.Vector- [exec] [exec] Missing javadocs were found! Anyone have a clue? I don't see Jenkins failures for this so maybe it's just me somehow. Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
[jira] [Commented] (SOLR-12200) ZkControllerTest failure. Leaking Overseer
[
https://issues.apache.org/jira/browse/SOLR-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437848#comment-16437848
]
Mikhail Khludnev commented on SOLR-12200:
-
Continuing to adding more debug and observing leak failures. Here is how one
test is finishing
{quote}
2> 70559 DEBUG (TEST-ZkControllerTest.testGetHostName-seed#[21CB3E792F7FAB5])
[n:127.0.0.1:8983_solr] o.a.s.c.a.ScheduledTriggers Shutting down action
executor now
2> 70592 WARN (OverseerExitThread) [] o.a.s.c.Overseer I'm exiting, but
I'm still the leader
..
2> 70594 WARN
(OverseerAutoScalingTriggerThread-72100555224645634-127.0.0.1:8983_solr-n_00)
[] o.a.s.c.a.OverseerTriggerThread OverseerTriggerThread has been closed,
exiting.
2> 70594 INFO (TEST-ZkControllerTest.testGetHostName-seed#[21CB3E792F7FAB5])
[n:127.0.0.1:8983_solr] o.a.s.c.u.ObjectReleaseTracker releasing
Overseer@1511021387 id=72100555224645634-127.0.0.1:8983_solr-n_00
closed=true
..
2> 70596 INFO (OverseerExitThread) [] o.a.s.c.Overseer
org.apache.solr.cloud.Overseer$ClusterStateUpdater@72cdd73e is *NOT* shutting
down, Then it needs to rejoin election
..
2> 70602 INFO (OverseerExitThread) [] o.a.s.c.Overseer turning
Overseer@1511021387 id=72100555224645634-127.0.0.1:8983_solr-n_00
closed=true to Overseer@1511021387
id=72100555224645634-127.0.0.1:8983_solr-n_01 closed=true
2> 70602 INFO (OverseerExitThread) [] o.a.s.c.Overseer
Overseer@1511021387 id=72100555224645634-127.0.0.1:8983_solr-n_01
closed=false is starting
2> 70612 INFO (OverseerExitThread) [] o.a.s.c.Overseer tracking
Overseer@1511021387 id=72100555224645634-127.0.0.1:8983_solr-n_01
closed=false
// *leak*
2> 70612 INFO (OverseerExitThread) [] o.a.s.c.u.ObjectReleaseTracker
tracking Overseer@1511021387
id=72100555224645634-127.0.0.1:8983_solr-n_01
closed=false=>org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException:
org.apache.solr.cloud.Overseer
2>at
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:41)
2>at org.apache.solr.cloud.Overseer.start(Overseer.java:548)
2>at
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:851)
2>at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
2>at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
2>at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
2>at
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)
2>at
org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:2069)
2>at
org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:331)
2>at java.lang.Thread.run(Thread.java:745)
2> 70616 INFO (TEST-ZkControllerTest.testGetHostName-seed#[21CB3E792F7FAB5])
[n:127.0.0.1:8983_solr] o.a.s.c.CoreContainer Shutting down CoreContainer
instance=1058782550
{quote}
The most suspicious thing is that *is NOT shutting down, Then it needs to
rejoin election* while test is definitely is shutting down.
> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, tests-failures.txt,
> tests-failures.txt.gz, zk.fail.txt.gz
>
>
> Failure seems suspiciously the same.
>[junit4] 2> 499919 INFO
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77])
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4] 2> 499920 INFO
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4] 2> 499920 ERROR
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
> [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4] 2> java.lang.InterruptedException: null
>[junit4] 2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4] 2>at java.lang.Object.wait(Object.java:502)
> ~[?:1.8.0_152]
>[junit4] 2>at
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409)
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due
> to leaking Overseer.
--
This message was sent by Atlassian JIRA
(v7.6.3
[jira] [Commented] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437830#comment-16437830 ] David Smiley commented on LUCENE-8248: -- Thanks Mike Sokolov; the inconsistent name was an irritation to me. (Thanks to Mike McCandless too for the review & commit work) > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437829#comment-16437829 ] ASF subversion and git services commented on LUCENE-8248: - Commit 0836ea5c385250bc02ca3a02e0d395e53ee3267e in lucene-solr's branch refs/heads/branch_7x from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0836ea5 ] LUCENE-8248: MergePolicyWrapper is renamed to FilterMergePolicy and now also overrides getMaxCFSSegmentSizeMB > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437806#comment-16437806 ] ASF subversion and git services commented on LUCENE-8248: - Commit 7c0387ad3fa7985564350a0cd16694905e66619d in lucene-solr's branch refs/heads/master from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c0387a ] LUCENE-8248: MergePolicyWrapper is renamed to FilterMergePolicy and now also overrides getMaxCFSSegmentSizeMB > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437766#comment-16437766 ] Michael McCandless commented on LUCENE-8248: Thanks [~msoko...@gmail.com]; new patch looks great; I'll push shortly! > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-12045) Move Analytics Component from contrib to core
[ https://issues.apache.org/jira/browse/SOLR-12045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437754#comment-16437754 ] David Smiley commented on SOLR-12045: - I'm not sure where best to bring this up but I'm concerned about all the ways there are to compute facets in Solr. Each needs to be maintained, documented, and then in the end Solr is more complex -- albeit maybe more capable though i really don't know right now where the gaps are. It would love to see some particular use-cases compared in terms of syntax and performance, and of course a better understanding of extra capabilities unique to each. The primary contenders are the JSON-Facets module & this Analytics module. Of course this is wishful thinking; I can't implore anyone to do anything. Well except for my kids but they are not up to this task yet LOL :-) I've seen presentations on both individually that made each out to be awesome but at no times were they compared. > Move Analytics Component from contrib to core > - > > Key: SOLR-12045 > URL: https://issues.apache.org/jira/browse/SOLR-12045 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (8.0) >Reporter: Houston Putman >Priority: Major > Fix For: master (8.0) > > Time Spent: 10m > Remaining Estimate: 0h > > The Analytics Component currently lives in contrib. Since it includes no > external dependencies, there is no harm in moving it into core solr. > The analytics component would be included as a default search component and > the analytics handler (currently only used for analytics shard requests, > might be transitioned to handle user requests in the future) would be > included as an implicit handler. -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437745#comment-16437745 ] Mike Sokolov commented on LUCENE-8248: -- I think this build failed due to some files missing from the commit; I had neglected to "git add" the new files so they were not in the patch ... > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Sokolov updated LUCENE-8248: - Attachment: LUCENE-8248.patch > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > -- > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index >Reporter: Mike Sokolov >Priority: Minor > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- 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-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
[
https://issues.apache.org/jira/browse/SOLR-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer resolved SOLR-10513.
---
Resolution: Fixed
Committed on master and branch_7x. Thank you [~sarkaramr...@gmail.com] and
[~asingh2411] .
> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
>
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch,
> SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
> if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
> } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
> }
> } catch (UnsupportedOperationException uoe) {
> // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by
> references. So if you are using 2 or more spellcheckers with same distance
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method.
> This does not solve the problem yet, because the *default equals* method
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .
> Moreover, Some check of similar sorts should also be in the init method. So
> that user does not have to wait for this error during query time. If the
> spellcheck components have been added *solrconfig.xml* , it should throw
> error during core-reload itself.
--
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-12223) Document 'Initial Startup' for bidirectional approach in CDCR
[
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-12223:
Summary: Document 'Initial Startup' for bidirectional approach in CDCR
(was: Document 'Initial Startup' for bidirectional approach for CDCR)
> Document 'Initial Startup' for bidirectional approach in CDCR
> -
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-12223.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-12223) Document 'Initial Startup' for bidirectional approach for CDCR
[
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-12223:
Attachment: SOLR-12223.patch
> Document 'Initial Startup' for bidirectional approach for CDCR
> --
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-12223.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-12223) Document 'Initial Startup' for bidirectional approach for CDCR
[
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-12223:
Attachment: (was: SOLR-12068.patch)
> Document 'Initial Startup' for bidirectional approach for CDCR
> --
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-12223.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-12223) Document 'Initial Startup' for bidirectional approach for CDCR
[
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-12223:
Attachment: (was: SOLR-12068.patch)
> Document 'Initial Startup' for bidirectional approach for CDCR
> --
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-12068.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-12223) Document 'Initial Startup' for bidirectional approach for CDCR
[
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437706#comment-16437706
]
Amrit Sarkar commented on SOLR-12223:
-
Patch uploaded with necessary additions.
> Document 'Initial Startup' for bidirectional approach for CDCR
> --
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-12068.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-12223) Document 'Initial Startup' for bidirectional approach for CDCR
[
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-12223:
Attachment: SOLR-12068.patch
> Document 'Initial Startup' for bidirectional approach for CDCR
> --
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-12068.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-12223) Document 'Initial Startup' for bidirectional approach for CDCR
Amrit Sarkar created SOLR-12223:
---
Summary: Document 'Initial Startup' for bidirectional approach for
CDCR
Key: SOLR-12223
URL: https://issues.apache.org/jira/browse/SOLR-12223
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: CDCR, documentation
Affects Versions: 7.3
Reporter: Amrit Sarkar
Attachments: SOLR-12068.patch
Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-12223) Document 'Initial Startup' for bidirectional approach for CDCR
[
https://issues.apache.org/jira/browse/SOLR-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-12223:
Attachment: SOLR-12068.patch
> Document 'Initial Startup' for bidirectional approach for CDCR
> --
>
> Key: SOLR-12223
> URL: https://issues.apache.org/jira/browse/SOLR-12223
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR, documentation
>Affects Versions: 7.3
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-12068.patch
>
>
> Add {{Initial Startup}} for bidirectional approach to {{cdcr-config.html}}.
--
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-SmokeRelease-7.x - Build # 199 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/199/ No tests ran. Build Log: [...truncated 24217 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2186 links (1742 relative) to 2894 anchors in 228 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/changes -dist-keys: [get] Getting: http://home.apache.org/keys/group/lucene.asc [get] To: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/KEYS package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.4.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml r
[jira] [Commented] (SOLR-12221) Add valueAt Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437660#comment-16437660
]
ASF subversion and git services commented on SOLR-12221:
Commit 89ad4128bea7601219eac1d96c99597a78e9d30b in lucene-solr's branch
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89ad412 ]
SOLR-12221: Add valueAt Stream Evaluator
> Add valueAt Stream Evaluator
>
>
> Key: SOLR-12221
> URL: https://issues.apache.org/jira/browse/SOLR-12221
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12221.patch
>
>
> The *valueAt* Stream Evaluator returns the value at a specific index of an
> array or the value of a specific row and column of a matrix.
> Sample syntax for an array:
> {code:java}
> let(a=array(1, 2, 3),
> b=valueAt(a, 2)){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-12221) Add valueAt Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437650#comment-16437650
]
ASF subversion and git services commented on SOLR-12221:
Commit 487daab62978b9e331ffa59ce6be2b527e6b5526 in lucene-solr's branch
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=487daab ]
SOLR-12221: Add valueAt Stream Evaluator
> Add valueAt Stream Evaluator
>
>
> Key: SOLR-12221
> URL: https://issues.apache.org/jira/browse/SOLR-12221
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12221.patch
>
>
> The *valueAt* Stream Evaluator returns the value at a specific index of an
> array or the value of a specific row and column of a matrix.
> Sample syntax for an array:
> {code:java}
> let(a=array(1, 2, 3),
> b=valueAt(a, 2)){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-Windows (64bit/jdk-9.0.4) - Build # 7269 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7269/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.common.util.TestTimeSource.testEpochTime Error Message: SimTimeSource:50.0 time diff=13457650 Stack Trace: java.lang.AssertionError: SimTimeSource:50.0 time diff=13457650 at __randomizedtesting.SeedInfo.seed([C5B751D038743042:FDDB22F5ACA49204]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.common.util.TestTimeSource.doTestEpochTime(TestTimeSource.java:48) at org.apache.solr.common.util.TestTimeSource.testEpochTime(TestTimeSource.java:32) 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: [...truncated 1870 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\temp\junit4-J1-20180413_155455_769102695747818641
[jira] [Resolved] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved LUCENE-8251.
-
Resolution: Fixed
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597,
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038
> -58.984559858566556,0.0 -3.68E-321,-66.33598777585381
> -7.382056816201731,135.63207358036593 -51.43541696593334))
> WKT: POINT(0.005183505059185348 1.98E-321)
> normal polygon: false
> large polygon: true
> at
> __randomizedtesting.SeedInfo.seed([C1E5FF7FBC7AC980:47CE8D3C5A69
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437534#comment-16437534
]
ASF subversion and git services commented on LUCENE-8251:
-
Commit 2863fce4e149f2086347f3956717794a252591aa in lucene-solr's branch
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2863fce ]
LUCENE-8251: Handle near-parallelness with envelope plane by a progressive
adjoining point distance increment, up to 100 iterations. Then, give up and
assume a crossing.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.0
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437532#comment-16437532
]
ASF subversion and git services commented on LUCENE-8251:
-
Commit 368bdf36c117dafb6c793d787f1863e219352c31 in lucene-solr's branch
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=368bdf3 ]
LUCENE-8251: Handle near-parallelness with envelope plane by a progressive
adjoining point distance increment, up to 100 iterations. Then, give up and
assume a crossing.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.0
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437531#comment-16437531
]
ASF subversion and git services commented on LUCENE-8251:
-
Commit d78c354bef3dd451ab584c7fe71bb614696d7fd6 in lucene-solr's branch
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d78c354 ]
LUCENE-8251: Handle near-parallelness with envelope plane by a progressive
adjoining point distance increment, up to 100 iterations. Then, give up and
assume a crossing.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.0469
[jira] [Resolved] (LUCENE-8252) ArrayIndexOutOfBoundsException hit in lucene50.ForUtil.readBlock
[
https://issues.apache.org/jira/browse/LUCENE-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand resolved LUCENE-8252.
--
Resolution: Invalid
This error indicates that your shard is corrupt indeed. We automatically verify
checksums on merge since we need to read the data for the merge anyway, so it
only introduces little additional CPU overhead. However checking a read-only
index that is heavily searched is more challenging since you don't want the
checksum verifications to trash your I/O cache.
> ArrayIndexOutOfBoundsException hit in lucene50.ForUtil.readBlock
>
>
> Key: LUCENE-8252
> URL: https://issues.apache.org/jira/browse/LUCENE-8252
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.6.2
>Reporter: Michael Braun
>Priority: Major
>
> We hit this on an autowarming query with a phrase on a particular shard, and
> it keeps happening with similar errors (and on other position-sensitive
> queries) post-restart on both that particular autowarming query and other
> queries. I'm guessing somehow a file in the index got written incorrectly
> with regard to positions.
> {code}
> 10:11:58 ERROR 04-06 17:52:06.360 org.apache.solr.handler.RequestHandlerBase
> (searcherExecutor-9-thread-1-processing-n:ourip:8983_solr
> x:collection_shardY_replica1 s:shardY c:collection) [s:Y ]
> java.lang.ArrayIndexOutOfBoundsException: -95
> at
> org.apache.lucene.codecs.lucene50.ForUtil.readBlock(ForUtil.java:196)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.refillPositions(Lucene50PostingsReader.java:638)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.skipPositions(Lucene50PostingsReader.java:747)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.nextPosition(Lucene50PostingsReader.java:768)
> at
> org.apache.lucene.search.ExactPhraseScorer.phraseFreq(ExactPhraseScorer.java:128)
> at
> org.apache.lucene.search.ExactPhraseScorer.access$000(ExactPhraseScorer.java:27)
> at
> org.apache.lucene.search.ExactPhraseScorer$1.matches(ExactPhraseScorer.java:73)
> at
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:253)
> at
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:197)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:668)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:472)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:217)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1582)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1399)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:566)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:545)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> at
> org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:74)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> 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)
> {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-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
[
https://issues.apache.org/jira/browse/SOLR-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437511#comment-16437511
]
ASF subversion and git services commented on SOLR-10513:
Commit 6d771dcc9f0c6cbb33b1b5cf6c60f126713d9555 in lucene-solr's branch
refs/heads/branch_7x from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6d771dc ]
SOLR-10513: Implement .equals() for LuceneLevenshteinDistance.
> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
>
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch,
> SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
> if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
> } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
> }
> } catch (UnsupportedOperationException uoe) {
> // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by
> references. So if you are using 2 or more spellcheckers with same distance
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method.
> This does not solve the problem yet, because the *default equals* method
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .
> Moreover, Some check of similar sorts should also be in the init method. So
> that user does not have to wait for this error during query time. If the
> spellcheck components have been added *solrconfig.xml* , it should throw
> error during core-reload itself.
--
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-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
[
https://issues.apache.org/jira/browse/SOLR-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437504#comment-16437504
]
ASF subversion and git services commented on SOLR-10513:
Commit 12bd5f9448f70b9fdc450dac916dbd1a83edafbc in lucene-solr's branch
refs/heads/master from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=12bd5f9 ]
SOLR-10513: Implement .equals() for LuceneLevenshteinDistance.
> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
>
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch,
> SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
> if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
> } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
> }
> } catch (UnsupportedOperationException uoe) {
> // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by
> references. So if you are using 2 or more spellcheckers with same distance
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method.
> This does not solve the problem yet, because the *default equals* method
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .
> Moreover, Some check of similar sorts should also be in the init method. So
> that user does not have to wait for this error during query time. If the
> spellcheck components have been added *solrconfig.xml* , it should throw
> error during core-reload itself.
--
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-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
[
https://issues.apache.org/jira/browse/SOLR-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-10513:
--
Fix Version/s: (was: 5.5)
7.4
> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
>
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch,
> SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch, SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
> if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
> } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
> }
> } catch (UnsupportedOperationException uoe) {
> // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by
> references. So if you are using 2 or more spellcheckers with same distance
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method.
> This does not solve the problem yet, because the *default equals* method
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .
> Moreover, Some check of similar sorts should also be in the init method. So
> that user does not have to wait for this error during query time. If the
> spellcheck components have been added *solrconfig.xml* , it should throw
> error during core-reload itself.
--
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-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-11913.
-
Resolution: Fixed
I'm really not sure why TestReqParamsAPI didn't fail on the earlier test run --
weird.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
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-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437490#comment-16437490
]
ASF subversion and git services commented on SOLR-11913:
Commit a4f60c286319d2e46fb76f5461e8aa1101f8b9e0 in lucene-solr's branch
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a4f60c2 ]
SOLR-11913: SolrParams now implements Iterable>
and has stream()
(cherry picked from commit 9a149ad)
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
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-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437487#comment-16437487
]
ASF subversion and git services commented on SOLR-11913:
Commit 9a149ad7e77837b7a99e84a4968fe43747ec30a0 in lucene-solr's branch
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9a149ad ]
SOLR-11913: SolrParams now implements Iterable>
and has stream()
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
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-Solaris (64bit/jdk1.8.0) - Build # 558 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/558/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.index.hdfs.CheckHdfsIndexTest.testChecksumsOnlyVerbose Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:38262 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:38262 at __randomizedtesting.SeedInfo.seed([C75387FB1972A7FC:31F17EDB577C01E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886) 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.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:322) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) 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.ja
[jira] [Commented] (SOLR-12186) XPathEntityProcessor with useSolrAddSchema does not add nested child documents
[
https://issues.apache.org/jira/browse/SOLR-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437473#comment-16437473
]
Alexandre Rafalovitch commented on SOLR-12186:
--
Is this connected to SOLR-9477? A bit hard to say for sure.
> XPathEntityProcessor with useSolrAddSchema does not add nested child documents
> --
>
> Key: SOLR-12186
> URL: https://issues.apache.org/jira/browse/SOLR-12186
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: 7.1
>Reporter: Cetra Free
>Priority: Major
>
> When using {{useSolrAddSchema=true}} this does not support child nested
> documents as per the normal update handler.
> I would expect this to either be mentioned in the documentation as a
> limitation, or supported.
--
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-8252) ArrayIndexOutOfBoundsException hit in lucene50.ForUtil.readBlock
[
https://issues.apache.org/jira/browse/LUCENE-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437461#comment-16437461
]
Michael Braun commented on LUCENE-8252:
---
Aha thanks - sorry, had thought it checked checksums on load rather than
requiring a checkindex to verify just that piece-
{code}
test: check integrity.FAILED
WARNING: exorciseIndex() would remove reference to this segment; full
exception:
org.apache.lucene.index.CorruptIndexException: checksum failed (hardware
problem?) : expected=92621dd7 actual=87fba3fa
(resource=BufferedChecksumIndexInput(MMapIndexInput(path=".../collection/collection_shardY_replica1/data/index.20180403111745790/_24ov_Lucene50_0.pos")))
at org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:419)
at
org.apache.lucene.codecs.CodecUtil.checksumEntireFile(CodecUtil.java:526)
at
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader.checkIntegrity(Lucene50PostingsReader.java:1286)
at
org.apache.lucene.codecs.blocktree.BlockTreeTermsReader.checkIntegrity(BlockTreeTermsReader.java:339)
at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.checkIntegrity(PerFieldPostingsFormat.java:348)
at
org.apache.lucene.index.CodecReader.checkIntegrity(CodecReader.java:374)
at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:708)
at org.apache.lucene.index.CheckIndex.doCheck(CheckIndex.java:2771)
at org.apache.lucene.index.CheckIndex.doMain(CheckIndex.java:2673)
at org.apache.lucene.index.CheckIndex.main(CheckIndex.java:2599)
{code}
If this is expected to happen on occasion and checksum checking is only done on
checkindex, then this jira should be withdrawn. Thanks for your help [~jpountz]
> ArrayIndexOutOfBoundsException hit in lucene50.ForUtil.readBlock
>
>
> Key: LUCENE-8252
> URL: https://issues.apache.org/jira/browse/LUCENE-8252
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.6.2
>Reporter: Michael Braun
>Priority: Major
>
> We hit this on an autowarming query with a phrase on a particular shard, and
> it keeps happening with similar errors (and on other position-sensitive
> queries) post-restart on both that particular autowarming query and other
> queries. I'm guessing somehow a file in the index got written incorrectly
> with regard to positions.
> {code}
> 10:11:58 ERROR 04-06 17:52:06.360 org.apache.solr.handler.RequestHandlerBase
> (searcherExecutor-9-thread-1-processing-n:ourip:8983_solr
> x:collection_shardY_replica1 s:shardY c:collection) [s:Y ]
> java.lang.ArrayIndexOutOfBoundsException: -95
> at
> org.apache.lucene.codecs.lucene50.ForUtil.readBlock(ForUtil.java:196)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.refillPositions(Lucene50PostingsReader.java:638)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.skipPositions(Lucene50PostingsReader.java:747)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.nextPosition(Lucene50PostingsReader.java:768)
> at
> org.apache.lucene.search.ExactPhraseScorer.phraseFreq(ExactPhraseScorer.java:128)
> at
> org.apache.lucene.search.ExactPhraseScorer.access$000(ExactPhraseScorer.java:27)
> at
> org.apache.lucene.search.ExactPhraseScorer$1.matches(ExactPhraseScorer.java:73)
> at
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:253)
> at
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:197)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:668)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:472)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:217)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1582)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1399)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:566)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:545)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> at
> org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:74)
> at
> org.apache.sol
[jira] [Commented] (SOLR-12196) Prepare Admin UI for migrating to Angular.io
[ https://issues.apache.org/jira/browse/SOLR-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437447#comment-16437447 ] Alexandre Rafalovitch commented on SOLR-12196: -- >From all I have read, the migration from Angular 1 to later version is a real >piece of re-engineering as well. In that sense, migrating to React or Vue are >probably the projects of similar complexity. My vote would probably be for React as there are still more integrations with it and more possibilities (native mobile UI with React Native!?!). And given the amount of work, I wonder if that's also a good time to collect larger level ideas on what UI should look like, given the prominence of Javascript and availability of self-descriptive and management Solr APIs. > Prepare Admin UI for migrating to Angular.io > > > Key: SOLR-12196 > URL: https://issues.apache.org/jira/browse/SOLR-12196 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Labels: Angular, AngularJS, angular-migration > Fix For: master (8.0) > > > AngularJS is soon end of life, it [enters LTS in july > 2018|https://docs.angularjs.org/misc/version-support-status], whereupon it > will only receive fixes to serious bugs. Solr uses AngularJS 1.3 (the latest > AngularJS will be 1.7). > This issue is *not* for upgrading to Angular5/6, but to start preparing the > existing UI for easier migration later on. See > [https://angular.io/guide/upgrade]. > This JIRA will likely get multiple sub tasks such as > * Change to [Folders-by-Feature > Structure|https://angular.io/guide/upgrade#follow-the-angularjs-style-guide], > i.e. mix html, css, js in a folder based on feature > * Use a [Module > Loader|https://angular.io/guide/upgrade#using-a-module-loader] like > [Webpack|https://webpack.js.org/] > * Use [Component > Directives|https://angular.io/guide/upgrade#using-component-directives] > (requires first move from AngularJS 1.3 to 1.5) > The rationale for this lira is recognising how central the Admin UI is to > Solr, not letting it rot on top of a dying framework. Better to start moving > step by step and [perhaps write all new views in Angular > 5|https://angular.io/guide/upgrade#upgrading-with-ngupgrade], than to fall > further and further behind. > This effort of course assumes that Angular.io is the path we want to go, and > not React, VueJS or some other new kid on the block :) -- 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-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437436#comment-16437436
]
Karl Wright commented on LUCENE-8251:
-
We should be able to detect this situation with adjoining points, by seeing if
the adjoining points are on the very same envelope plane we computed
intersection with. That might lead is to be able to increase the separation of
adjoining points until we're finally able to detect crossings.
The problem with that approach is there's no guarantee that we will *ever*
leave the envelope plane. In the case of essential parallelism, though, it may
be safe to count it as a crossing.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437432#comment-16437432
]
Karl Wright commented on LUCENE-8251:
-
Confirmed that the envelope plane and the edge plane are nearly parallel.
Adjoining points on the edge plane that are ~1e-12 away from the intersection
point are still just about the same distance from the travel plane as before:
{code}
[junit4] 1> TestPoint plane: [lat=-1.1675693914784415,
lon=-1.8506150182993802E-4([X=0.39171238223740795, Y=-7.249088256978756E-5,
Z=-0.9182146655290553])] -> [X=1.0011188498955597, Y=-7.249088256978756E-5,
Z=-5.4114167758588356E-5]
[junit4] 1> Travel plane:
[1.0011188498955597,9.057045181228716E-5,3.5E-323] -> [X=1.0011188498955597,
Y=-7.249088256978756E-5, Z=-5.4114167758588356E-5]
[junit4] 1>
[junit4] 1> Considering edge [lat=-0.12884119701201008,
lon=-1.1577813992513593([X=0.39846895697760487, Y=-0.9092889699600809,
Z=-0.1286216320286114])] -> [lat=-0.8977173781916888,
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619
867484, Z=-0.7811731004355484])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-6.4E-323,
lon=0.0([X=1.0011188539924791, Y=0.0, Z=-6.4E-323])] ->
[lat=-0.12884119701201008, lon=-1.1577813992513593([X=0.39846895697760487,
Y=-0.9092889699600809, Z=-0.1286216320286114])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-1.0294747773716673,
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
Z=-0.8558716366345036])] -> [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
Y=0.0, Z=-6.4E-323])]
[junit4] 1> Edge intersects travel or testPoint plane
[junit4] 1> Assessing inner crossings...
[junit4] 1> Assessing travel envelope intersection point
[X=1.0011188498945593, Y=4.374699550797305E-5, Z=-7.90512123316076E-5],
travelPlane distance=-1.000310945187266E-12...
[junit4] 1>Adjoining point [X=1.0011188498945593,
Y=4.374699502377152E-5, Z=-7.905121145665111E-5] (intersection dist =
9.99942608793E-13; travelPlane dist=-1.000310945187266E-12; testPointPlane
dist=1.1623787759355908E-4) is not within
[junit4] 1>Adjoining point [X=1.0011188498945591,
Y=4.3746995992174576E-5, Z=-7.905121320656408E-5] (intersection dist =
1.37738338E-12; travelPlane dist=-1.000532989792191E-12; testPointPlane
dist=1.1623787856196213E-4) is not within
[junit4] 1> Assessing outer crossings...
[junit4] 1> Assessing travel envelope intersection point
[X=1.00111884989656, Y=4.3736315090256196E-5, Z=-7.903191272122474E-5],
travelPlane distance=1.000310945187266E-12...
[junit4] 1>Adjoining point [X=1.00111884989656,
Y=4.3736314606054664E-5, Z=-7.903191184626825E-5] (intersection dist =
9.99942608793E-13; travelPlane dist=1.000310945187266E-12; testPointPlane
dist=1.1622719717584222E-4) is not within
[junit4] 1>Adjoining point [X=1.0011188498965597,
Y=4.373631557445772E-5, Z=-7.903191359618122E-5] (intersection dist =
1.37738338E-12; travelPlane dist=1.88900582341E-12; testPointPlane
dist=1.1622719814424528E-4) is not within
{code}
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.1
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1708 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1708/ Java: 32bit/jdk1.8.0_162 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithKerberosAlt.testBasics Error Message: Address already in use Stack Trace: java.net.BindException: Address already in use at __randomizedtesting.SeedInfo.seed([D6430F4E41A290BC:EB9BA162794CCECC]:0) at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:433) at sun.nio.ch.Net.bind(Net.java:425) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252) at org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49) at org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525) at org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67) at org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65) 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) Build Log: [...truncated 13007 lines...] [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithKerberosAlt [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithKerberosAlt_D6430F4E41A290BC-001/init-core-data-001 [junit4] 2> 462849 WARN (SUITE-TestSolrCloudWithKerberosAlt-seed#[D6430F4E41A290BC]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2 [junit4] 2> 462850 INFO (SUITE-TestSolrCloudWithKerberosAlt-seed#[D6430F4E41A290BC]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 462852 INFO (SUITE-TestSolrCloudWithKerberosAlt-seed#[D6430F4E41A290BC]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN) [junit4] 2> 462852 INFO (SUITE-TestSolrCloudWithKerberosAlt-seed#[D6430F4E41A290BC]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 462856 INFO (TEST-TestSolrCloudWithKerberosAlt.testBasics-seed#[D6430F4E41A290BC]) [] o.a.s.SolrTestCaseJ4 ###Starting testBasics [junit4] 2> 473403 WARN (TEST-TestSolrCloudWithKerberosAlt.testBasics-seed#[D6430F4E41A290BC]) [] o.a.d.s.c.DefaultDirectoryService You didn't change the admin password of directory service instance 'DefaultKrbServer'. Please update the admin password as soon as possible to prevent a possible security breach. [junit4] 2> 475851 INFO (TEST-TestSolrCloudWithKerberosAlt.testBasics-seed#[D6430F4E41A290BC]) [] o.a.s.SolrTestCaseJ4 ###Ending testBasics [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestSolrCloudWithKerberosAlt -Dtests.method=testBasics -Dtests.seed=D6430F4E41A290BC -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es-DO -Dtests.timezone=Asia/Dhaka -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] ERROR 13.0s J0 | TestSolrCloudWithKerberosAlt.testBasics <<< [junit4]> Throwable #1: java.net.BindException: Address already in use [junit4]>at __randomizedtesting.SeedInfo.seed([D6430F4E41A290BC:EB9BA162794CCECC]:0) [junit4]>at sun.nio.ch.Net.bind0(Native Method) [junit4]>at sun.nio.ch.Net.bind(Net.java:433) [junit4]>at sun.nio.ch.Net.bind(Net.java:425) [junit4]>at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) [junit4]>at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) [junit4]>at org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252) [junit4]>at org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49) [junit4]>at org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525) [junit4]>at org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67) [junit4]>at org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409) [junit4]>at org.apache.mina.util.NamePreservingRunnable.ru
Re: What are other options for index backup/replication?
On 4/13/2018 5:28 AM, sandesh.yapuram wrote: > I have an application that uses lucene indexes and we generate a single > index for all data. > I want to take a weekly *local* backup of the index quitely and > asynchronously. Jan is correct that this mailing list isn't the right place for your question. Here's an idea, though: If your program is running on an OS and filesystem that supports hard links (Linux being a prime example), one thing you can do is make a hardlink copy of your index directory, and then copy from that hardlink copy to a backup location. Making hardlink copies is near-instant process, and once it's made, you can continue to update the index while you are making a backup of the hardlink copy. Then once your backup is made, delete the hardlink copy. If you're on Windows or another OS that doesn't readily support hard links, you could look into how Solr creates backups of Lucene indexes for SolrCloud. All that source code is available -- it's in the same source repository as Lucene. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437407#comment-16437407
]
Karl Wright commented on LUCENE-8251:
-
Things have quieted down enough so I can look at this some more.
The first thing I noted was that we've got detected intersections with both
inner and outer envelopes for the travel plane. But they aren't discovered to
be crossings -- because when you start at the intersection point and move along
the edge a small distance either way, you're not inside the actual travel plane
zone:
{code}
[junit4] 1> TestPoint plane: [lat=-1.1675693914784415,
lon=-1.8506150182993802E-4([X=0.39171238223740795, Y=-7.249088256978756E-5,
Z=-0.9182146655290553])] -> [X=1.0011188498955597, Y=-7.249088256978756E-5,
Z=-5.4114167758588356E-5]
[junit4] 1> Travel plane:
[1.0011188498955597,9.057045181228716E-5,3.5E-323] -> [X=1.0011188498955597,
Y=-7.249088256978756E-5, Z=-5.4114167758588356E-5]
[junit4] 1>
[junit4] 1> Considering edge [lat=-0.12884119701201008,
lon=-1.1577813992513593([X=0.39846895697760487, Y=-0.9092889699600809,
Z=-0.1286216320286114])] -> [lat=-0.8977173781916888,
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619
867484, Z=-0.7811731004355484])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-6.4E-323,
lon=0.0([X=1.0011188539924791, Y=0.0, Z=-6.4E-323])] ->
[lat=-0.12884119701201008, lon=-1.1577813992513593([X=0.39846895697760487,
Y=-0.9092889699600809, Z=-0.1286216320286114])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-1.0294747773716673,
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
Z=-0.8558716366345036])] -> [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
Y=0.0, Z=-6.4E-323])]
[junit4] 1> Edge intersects travel or testPoint plane
[junit4] 1> Assessing inner crossings...
[junit4] 1> Assessing travel envelope intersection point
[X=1.0011188498945593, Y=4.374699550797305E-5, Z=-7.90512123316076E-5]...
[junit4] 1>Adjoining point [X=1.0011188498945593,
Y=4.374699502377152E-5, Z=-7.905121145665111E-5] (dist = 9.99942608793E-13)
is not within
[junit4] 1>Adjoining point [X=1.0011188498945591,
Y=4.3746995992174576E-5, Z=-7.905121320656408E-5] (dist =
1.37738338E-12) is not within
[junit4] 1> Assessing outer crossings...
[junit4] 1> Assessing travel envelope intersection point
[X=1.00111884989656, Y=4.3736315090256196E-5, Z=-7.903191272122474E-5]...
[junit4] 1>Adjoining point [X=1.00111884989656,
Y=4.3736314606054664E-5, Z=-7.903191184626825E-5] (dist =
9.99942608793E-13) is not within
[junit4] 1>Adjoining point [X=1.0011188498965597,
Y=4.373631557445772E-5, Z=-7.903191359618122E-5] (dist =
1.37738338E-12) is not within
{code}
If the edge plane were parallel, or nearly parallel, to the envelope plane,
that might explain it -- and I think that may actually be the case.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.445226
Re: Precommit failures
Thanks all! On Thu, Apr 12, 2018 at 8:28 PM, Karl Wright wrote: > I've been having inconsistent runs of precommit. Sometimes it complains, > sometimes not. But easily fixed -- I'll push javadoc now. > > Karl > > On Thu, Apr 12, 2018 at 8:50 PM, Erick Erickson > wrote: >> >> I'm getting this precommit failure on a fresh clone of master: >> >> -documentation-lint: >> >> [echo] checking for broken html... >> >> [jtidy] Checking for broken html (such as invalid tags)... >> >>[delete] Deleting directory >> /Users/Erick/apache/solrVersions/solr-12028/lucene/build/jtidy_tmp >> [echo] Checking for broken links... >> [exec] >> [exec] Crawl/parse... >> [exec] >> [exec] Verify... >> [echo] Checking for missing docs... >> [exec] >> [exec] >> build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html >> [exec] missing Methods: strictlyWithin-double-double-double- >> [exec] missing Methods: >> strictlyWithin-org.apache.lucene.spatial3d.geom.Vector- >> [exec] >> [exec] Missing javadocs were found! >> >> Anyone have a clue? I don't see Jenkins failures for this so maybe >> it's just me somehow. >> >> Erick >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8252) ArrayIndexOutOfBoundsException hit in lucene50.ForUtil.readBlock
[
https://issues.apache.org/jira/browse/LUCENE-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437365#comment-16437365
]
Adrien Grand commented on LUCENE-8252:
--
Can you run CheckIndex on this index to check whether this is a bug or your
index is corrupt?
> ArrayIndexOutOfBoundsException hit in lucene50.ForUtil.readBlock
>
>
> Key: LUCENE-8252
> URL: https://issues.apache.org/jira/browse/LUCENE-8252
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 6.6.2
>Reporter: Michael Braun
>Priority: Major
>
> We hit this on an autowarming query with a phrase on a particular shard, and
> it keeps happening with similar errors (and on other position-sensitive
> queries) post-restart on both that particular autowarming query and other
> queries. I'm guessing somehow a file in the index got written incorrectly
> with regard to positions.
> {code}
> 10:11:58 ERROR 04-06 17:52:06.360 org.apache.solr.handler.RequestHandlerBase
> (searcherExecutor-9-thread-1-processing-n:ourip:8983_solr
> x:collection_shardY_replica1 s:shardY c:collection) [s:Y ]
> java.lang.ArrayIndexOutOfBoundsException: -95
> at
> org.apache.lucene.codecs.lucene50.ForUtil.readBlock(ForUtil.java:196)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.refillPositions(Lucene50PostingsReader.java:638)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.skipPositions(Lucene50PostingsReader.java:747)
> at
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.nextPosition(Lucene50PostingsReader.java:768)
> at
> org.apache.lucene.search.ExactPhraseScorer.phraseFreq(ExactPhraseScorer.java:128)
> at
> org.apache.lucene.search.ExactPhraseScorer.access$000(ExactPhraseScorer.java:27)
> at
> org.apache.lucene.search.ExactPhraseScorer$1.matches(ExactPhraseScorer.java:73)
> at
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:253)
> at
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:197)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:668)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:472)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:217)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1582)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1399)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:566)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:545)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
> at
> org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:74)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> 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)
> {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] [Created] (LUCENE-8252) ArrayIndexOutOfBoundsException hit in lucene50.ForUtil.readBlock
Michael Braun created LUCENE-8252:
-
Summary: ArrayIndexOutOfBoundsException hit in
lucene50.ForUtil.readBlock
Key: LUCENE-8252
URL: https://issues.apache.org/jira/browse/LUCENE-8252
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 6.6.2
Reporter: Michael Braun
We hit this on an autowarming query with a phrase on a particular shard, and it
keeps happening with similar errors (and on other position-sensitive queries)
post-restart on both that particular autowarming query and other queries. I'm
guessing somehow a file in the index got written incorrectly with regard to
positions.
{code}
10:11:58 ERROR 04-06 17:52:06.360 org.apache.solr.handler.RequestHandlerBase
(searcherExecutor-9-thread-1-processing-n:ourip:8983_solr
x:collection_shardY_replica1 s:shardY c:collection) [s:Y ]
java.lang.ArrayIndexOutOfBoundsException: -95
at org.apache.lucene.codecs.lucene50.ForUtil.readBlock(ForUtil.java:196)
at
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.refillPositions(Lucene50PostingsReader.java:638)
at
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.skipPositions(Lucene50PostingsReader.java:747)
at
org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockPostingsEnum.nextPosition(Lucene50PostingsReader.java:768)
at
org.apache.lucene.search.ExactPhraseScorer.phraseFreq(ExactPhraseScorer.java:128)
at
org.apache.lucene.search.ExactPhraseScorer.access$000(ExactPhraseScorer.java:27)
at
org.apache.lucene.search.ExactPhraseScorer$1.matches(ExactPhraseScorer.java:73)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:253)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:197)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:668)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:472)
at
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:217)
at
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1582)
at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1399)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:566)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:545)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:296)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2477)
at
org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:74)
at
org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
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)
{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 (32bit/jdk1.8.0_162) - Build # 21816 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21816/ Java: 32bit/jdk1.8.0_162 -server -XX:+UseG1GC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.search.TestBooleanScorer Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([ECE0039CCAA40312]:0) FAILED: org.apache.lucene.search.TestBooleanScorer.testSparseClauseOptimization Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([ECE0039CCAA40312]:0) Build Log: [...truncated 1972 lines...] [junit4] Suite: org.apache.lucene.search.TestBooleanScorer [junit4] 2> апр. 13, 2018 3:39:06 PM com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate [junit4] 2> WARNING: Suite execution timed out: org.apache.lucene.search.TestBooleanScorer [junit4] 2>1) Thread[id=2022, name=Lucene Merge Thread #56, state=WAITING, group=TGRP-TestBooleanScorer] [junit4] 2> at sun.misc.Unsafe.park(Native Method) [junit4] 2> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) [junit4] 2> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) [junit4] 2> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) [junit4] 2> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) [junit4] 2> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) [junit4] 2> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) [junit4] 2> at org.apache.lucene.search.LRUQueryCache.clearCoreCacheKey(LRUQueryCache.java:352) [junit4] 2> at org.apache.lucene.search.LRUQueryCache$$Lambda$24/16547955.onClose(Unknown Source) [junit4] 2> at org.apache.lucene.index.SegmentCoreReaders.lambda$notifyCoreClosedListeners$0(SegmentCoreReaders.java:196) [junit4] 2> at org.apache.lucene.index.SegmentCoreReaders$$Lambda$21/18498800.accept(Unknown Source) [junit4] 2> at org.apache.lucene.util.IOUtils.lambda$null$0(IOUtils.java:634) [junit4] 2> at org.apache.lucene.util.IOUtils$$Lambda$19/13100545.close(Unknown Source) [junit4] 2> at org.apache.lucene.util.IOUtils.close(IOUtils.java:88) [junit4] 2> at org.apache.lucene.util.IOUtils.applyToAll(IOUtils.java:634) [junit4] 2> at org.apache.lucene.index.SegmentCoreReaders.notifyCoreClosedListeners(SegmentCoreReaders.java:196) [junit4] 2> at org.apache.lucene.index.SegmentCoreReaders$$Lambda$20/12411627.close(Unknown Source) [junit4] 2> at org.apache.lucene.index.SegmentCoreReaders.decRef(SegmentCoreReaders.java:172) [junit4] 2> at org.apache.lucene.index.SegmentReader.doClose(SegmentReader.java:204) [junit4] 2> at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:244) [junit4] 2> at org.apache.lucene.index.ReadersAndUpdates.dropReaders(ReadersAndUpdates.java:228) [junit4] 2> at org.apache.lucene.index.IndexWriter$ReaderPool.drop(IndexWriter.java:563) [junit4] 2> at org.apache.lucene.index.IndexWriter.lambda$closeMergeReaders$1(IndexWriter.java:4410) [junit4] 2> at org.apache.lucene.index.IndexWriter$$Lambda$44/26866589.accept(Unknown Source) [junit4] 2> at org.apache.lucene.util.IOUtils.lambda$null$0(IOUtils.java:634) [junit4] 2> at org.apache.lucene.util.IOUtils$$Lambda$19/13100545.close(Unknown Source) [junit4] 2> at org.apache.lucene.util.IOUtils.close(IOUtils.java:88) [junit4] 2> at org.apache.lucene.util.IOUtils.applyToAll(IOUtils.java:634) [junit4] 2> at org.apache.lucene.index.IndexWriter.closeMergeReaders(IndexWriter.java:4398) [junit4] 2> at org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:4075) [junit4] 2> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4637) [junit4] 2> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4142) [junit4] 2> at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:625) [junit4] 2> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:662) [junit4] 2>2) Thread[id=1965, name=TEST-TestBooleanScorer.testSparseClauseOptimization-seed#[ECE0039CCAA40312], state=BLOCKED, group=TGRP-TestBooleanScorer] [junit4] 2> at java.lang.Object.wait(Native Method) [junit4] 2
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437314#comment-16437314
]
ASF subversion and git services commented on LUCENE-8251:
-
Commit 5d8b87e221263fcf6bc0b4554b61ae43c074a590 in lucene-solr's branch
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5d8b87e ]
LUCENE-8251: Add AwaitsFix for the tests that this issue covers.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597,
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.632073
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437315#comment-16437315
]
ASF subversion and git services commented on LUCENE-8251:
-
Commit a97738a659aebaae153168b7fdddee5709f2abc2 in lucene-solr's branch
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a97738a ]
LUCENE-8251: Add AwaitsFix for the tests that this issue covers.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597,
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.632073
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437313#comment-16437313
]
ASF subversion and git services commented on LUCENE-8251:
-
Commit 79350bd4dd31a67c05f08e6484561c38494d4773 in lucene-solr's branch
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=79350bd ]
LUCENE-8251: Add AwaitsFix for the tests that this issue covers.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597,
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.632073580
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437306#comment-16437306
]
Karl Wright commented on LUCENE-8251:
-
Here's a similar case:
{code}
[junit4]> Point: [lat=3.310332671314249E-4,
lon=-3.0E-323([X=1.0011187987699837, Y=-3.0E-323, Z=3.314036388489196E-4])]
[junit4]> WKT: POLYGON((0.2605244736823189 -4.368136428487497,0.0
-4.283522745751538E-243,-0.05551266494188662
0.08658374814251642,-0.23216835996485705 -0.8093540467004184,0.2605244736823189
-4.368136428487497))
[junit4]> WKT: POINT(-1.7E-321 0.018966809085057403)
{code}
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-3
[jira] [Comment Edited] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point
[
https://issues.apache.org/jira/browse/LUCENE-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437290#comment-16437290
]
Steve Rowe edited comment on LUCENE-8245 at 4/13/18 1:35 PM:
-
*edit*: I see LUCENE-8251 has been opened for the failing test below:
Reproducing seed for {{RandomGeoPolygonTest.testComparePolygons()}} from
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/545/]; reproduces for
me on Linux:
{noformat}
Checking out Revision 21f39627624fe4d2b80ca85fae8fdf2b26fd70b6
(refs/remotes/origin/branch_7x)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=RandomGeoPolygonTest -Dtests.method=testComparePolygons
-Dtests.seed=D6349E776359D46D -Dtests.slow=true -Dtests.locale=ms
-Dtests.timezone=Asia/Makassar -Dtests.asserts=true -Dtests.file.encoding=Cp1252
[junit4] FAILURE 0.15s J0 | RandomGeoPolygonTest.testComparePolygons
{seed=[D6349E776359D46D:C13F762B72BE3163]} <<<
[junit4]> Throwable #1: java.lang.AssertionError:
[junit4]> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.07623836285341265,
lon=0.00454700984778178([X=0.998181035951336, Y=0.004538770280526402,
Z=-0.07624825759433645])], [lat=-7.476157549743229E-245,
lon=0.0([X=1.0011188539924791, Y=0.0, Z=-7.484522278466162E-245])],
[lat=0.001511171483804436, lon=-9.688787797923482E-4([X=1.001117233304039,
Y=-9.699615469421312E-4, Z=0.0015128616766053018])], [lat=-0.01412589292926225,
lon=-0.004052102300342142([X=1.0010100824418215, Y=-0.004056217458151357,
Z=-0.01414121792996793])]], internalEdges={}}]}
[junit4]> Large polygon: GeoComplexPolygon:
{planetmodel=PlanetModel.WGS84, number of shapes=1, address=b597f211,
testPoint=[lat=-0.02220757682746917,
lon=-1.218087190149091E-4([X=1.000870329530105, Y=-1.2191473334305646E-4,
Z=-0.02223055955204728])], testPointInSet=true, shapes={
{[lat=-0.01412589292926225, lon=-0.004052102300342142([X=1.0010100824418215,
Y=-0.004056217458151357, Z=-0.01414121792996793])], [lat=-0.07623836285341265,
lon=0.00454700984778178([X=0.998181035951336, Y=0.004538770280526402,
Z=-0.07624825759433645])], [lat=-7.476157549743229E-245,
lon=0.0([X=1.0011188539924791, Y=0.0, Z=-7.484522278466162E-245])],
[lat=0.001511171483804436, lon=-9.688787797923482E-4([X=1.001117233304039,
Y=-9.699615469421312E-4, Z=0.0015128616766053018])]}}
[junit4]> Point: [lat=3.310332671314249E-4,
lon=-3.0E-323([X=1.0011187987699837, Y=-3.0E-323, Z=3.314036388489196E-4])]
[junit4]> WKT: POLYGON((0.2605244736823189 -4.368136428487497,0.0
-4.283522745751538E-243,-0.05551266494188662
0.08658374814251642,-0.23216835996485705 -0.8093540467004184,0.2605244736823189
-4.368136428487497))
[junit4]> WKT: POINT(-1.7E-321 0.018966809085057403)
[junit4]> normal polygon: false
[junit4]> large polygon: true
[junit4]>at
__randomizedtesting.SeedInfo.seed([D6349E776359D46D:C13F762B72BE3163]:0)
[junit4]>at
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testComparePolygons(RandomGeoPolygonTest.java:179)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]>at
java.base/java.lang.reflect.Method.invoke(Method.java:564)
[junit4]>at java.base/java.lang.Thread.run(Thread.java:841)
[junit4] 2> NOTE: test params are: codec=Lucene70,
sim=RandomSimilarity(queryNorm=false): {}, locale=ms, timezone=Asia/Makassar
[junit4] 2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 11-ea
(64-bit)/cpus=3,threads=1,free=73360360,total=97320960
{noformat}
was (Author: steve_rowe):
Reproducing seed for {{RandomGeoPolygonTest.testComparePolygons()}} from
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/545/]; reproduces for
me on Linux:
{noformat}
Checking out Revision 21f39627624fe4d2b80ca85fae8fdf2b26fd70b6
(refs/remotes/origin/branch_7x)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=RandomGeoPolygonTest -Dtests.method=testComparePolygons
-Dtests.seed=D6349E776359D46D -Dtests.slow=true -Dtests.locale=ms
-Dtests.timezone=Asia/Makassar -Dtests.asserts=true -Dtests.file.encoding=Cp1252
[junit4] FAILURE 0.15s J0 | RandomGeoPolygonTest.testComparePolygons
{seed=[D6349E776359D46D:C13F762B72BE3163]} <<<
[junit4]> Throwable #1: java.lang.AssertionError:
[junit4]> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.07623836285341265,
lon=0.00454700984778178([X=0.998181035951336, Y=0.004538770280526402,
Z=-0.07624825
[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point
[
https://issues.apache.org/jira/browse/LUCENE-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437290#comment-16437290
]
Steve Rowe commented on LUCENE-8245:
Reproducing seed for {{RandomGeoPolygonTest.testComparePolygons()}} from
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/545/]; reproduces for
me on Linux:
{noformat}
Checking out Revision 21f39627624fe4d2b80ca85fae8fdf2b26fd70b6
(refs/remotes/origin/branch_7x)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=RandomGeoPolygonTest -Dtests.method=testComparePolygons
-Dtests.seed=D6349E776359D46D -Dtests.slow=true -Dtests.locale=ms
-Dtests.timezone=Asia/Makassar -Dtests.asserts=true -Dtests.file.encoding=Cp1252
[junit4] FAILURE 0.15s J0 | RandomGeoPolygonTest.testComparePolygons
{seed=[D6349E776359D46D:C13F762B72BE3163]} <<<
[junit4]> Throwable #1: java.lang.AssertionError:
[junit4]> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.07623836285341265,
lon=0.00454700984778178([X=0.998181035951336, Y=0.004538770280526402,
Z=-0.07624825759433645])], [lat=-7.476157549743229E-245,
lon=0.0([X=1.0011188539924791, Y=0.0, Z=-7.484522278466162E-245])],
[lat=0.001511171483804436, lon=-9.688787797923482E-4([X=1.001117233304039,
Y=-9.699615469421312E-4, Z=0.0015128616766053018])], [lat=-0.01412589292926225,
lon=-0.004052102300342142([X=1.0010100824418215, Y=-0.004056217458151357,
Z=-0.01414121792996793])]], internalEdges={}}]}
[junit4]> Large polygon: GeoComplexPolygon:
{planetmodel=PlanetModel.WGS84, number of shapes=1, address=b597f211,
testPoint=[lat=-0.02220757682746917,
lon=-1.218087190149091E-4([X=1.000870329530105, Y=-1.2191473334305646E-4,
Z=-0.02223055955204728])], testPointInSet=true, shapes={
{[lat=-0.01412589292926225, lon=-0.004052102300342142([X=1.0010100824418215,
Y=-0.004056217458151357, Z=-0.01414121792996793])], [lat=-0.07623836285341265,
lon=0.00454700984778178([X=0.998181035951336, Y=0.004538770280526402,
Z=-0.07624825759433645])], [lat=-7.476157549743229E-245,
lon=0.0([X=1.0011188539924791, Y=0.0, Z=-7.484522278466162E-245])],
[lat=0.001511171483804436, lon=-9.688787797923482E-4([X=1.001117233304039,
Y=-9.699615469421312E-4, Z=0.0015128616766053018])]}}
[junit4]> Point: [lat=3.310332671314249E-4,
lon=-3.0E-323([X=1.0011187987699837, Y=-3.0E-323, Z=3.314036388489196E-4])]
[junit4]> WKT: POLYGON((0.2605244736823189 -4.368136428487497,0.0
-4.283522745751538E-243,-0.05551266494188662
0.08658374814251642,-0.23216835996485705 -0.8093540467004184,0.2605244736823189
-4.368136428487497))
[junit4]> WKT: POINT(-1.7E-321 0.018966809085057403)
[junit4]> normal polygon: false
[junit4]> large polygon: true
[junit4]>at
__randomizedtesting.SeedInfo.seed([D6349E776359D46D:C13F762B72BE3163]:0)
[junit4]>at
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testComparePolygons(RandomGeoPolygonTest.java:179)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]>at
java.base/java.lang.reflect.Method.invoke(Method.java:564)
[junit4]>at java.base/java.lang.Thread.run(Thread.java:841)
[junit4] 2> NOTE: test params are: codec=Lucene70,
sim=RandomSimilarity(queryNorm=false): {}, locale=ms, timezone=Asia/Makassar
[junit4] 2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 11-ea
(64-bit)/cpus=3,threads=1,free=73360360,total=97320960
{noformat}
> GeoComplexPolygon fails when intersection of travel plane with edge is near
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg,
> LUCENE-8245.patch, LUCENE-8245.patch, LUCENE-8245_Polygon.patch,
> LUCENE-8245_Random.patch, LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible
> that the above and below planes crosses different edges. In the current
> implementation one of the crosses is missed because we only check edges that
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of p
Re: What are other options for index backup/replication?
Your question is better suited for the java-user@lucene mailing list ... See https://home.apache.org/~hossman/#java-user -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 13. apr. 2018 kl. 13:28 skrev sandesh.yapuram : > > Hello, > I have an application that uses lucene indexes and we generate a single > index for all data. > I want to take a weekly *local* backup of the index quitely and > asynchronously. > So far I've tried: > 1. The replicator module - I found it very complicated for what I just want > to copy and paste indexes once in a week. I don't want to introduce a new > framework and much code change. > 2. I tried the SnapshotDeletionPolicy by taking the files off the > IndexCommit and copying all of them into backup folder. But I'm not sure if > this is a cleaner way to do it since the replicator module is performing lot > of other stuff behind the scene. > > Are there any other strategies I can try out? > > > > > -- > Sent from: > http://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
[jira] [Comment Edited] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437275#comment-16437275
]
Karl Wright edited comment on LUCENE-8251 at 4/13/18 1:00 PM:
--
Unfortunately I need to deal with some other burning issues at the moment, and
I have no idea how to fix this particular problem either, so I'm going to have
to put it on hold until I think of something workable.
Next steps: First, validate the picture that the reason that the intersections
aren't getting detected is because they'd be off the ellipsoid. This can be
done in theory by seeing if the Plane.findIntersections code finds zero
solutions for the intersection in question. I bet it does, and that would
confirm the picture.
was (Author: kwri...@metacarta.com):
Unfortunately I need to deal with some other burning issues at the moment, and
I have no idea how to fix this particular problem either, so I'm going to have
to put it on hold until I think of something workable.
Next steps: First, validate the picture that the reason that the intersections
aren't getting detected is because they'd be off the ellipsoid.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.3917123
Re: When did we stop shipping changes.html?
Ok, good to know it was intentional. Thank you for clarification, Alex. On 13 April 2018 at 08:56, Jan Høydahl wrote: > We DO ship/distribute Changes.html, see > http://www-us.apache.org/dist/lucene/solr/7.3.0/ in the changes folder > But inside the tarball there is only an index.html file linking to the > online versions, e.g. > http://lucene.apache.org/solr/7_3_0/changes/Changes.html That was > intentional. > CHANGES.txt is still inside the tarball though. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 12. apr. 2018 kl. 22:37 skrev Cassandra Targett : > > I won’t speak for Jan and Uwe who worked on the patches there, but my > feeling is that it was specifically intended - the CHANGES entry for > SOLR-9450 says as much. > > Changes.html & associated files are built with the same ant target > (“documentation”) that builds javadocs. I think it was assumed that everyone > knew that (or would investigate if they had an interest), and would > understand that removing javadocs and replacing it with a single file would > also remove Changes.html from the /docs directory in the package. > > On Apr 12, 2018, at 3:15 PM, Alexandre Rafalovitch > wrote: > > > The scope of that JIRA was Javadocs specifically. > > Wouldn't loosing other files, such as changes.html be an unintended > consequences then? > > Regards, > Alex. > > On 12 April 2018 at 16:07, Cassandra Targett wrote: > > I believe it was in 6.5, with > https://issues.apache.org/jira/browse/SOLR-9450. > > On Apr 12, 2018, at 2:45 PM, Alexandre Rafalovitch > wrote: > > The Solr's doc folder is suddenly looking scarily empty. > > Specifically, the changes.html now seems to be only online. That quite > surprised me. Not that I am in love with the current changes.txt or > changes.html for my usual use case (finding when something became > available), but still. > > Worse, I could not figure out when that changes.html file stopped > being shipped by trying to read or grep through changes.txt (catch-22) > or Jiras. > > Could somebody please point me to the relevant issue where that was > discussed and executed for more context. > > Regards, > Alex. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons
[
https://issues.apache.org/jira/browse/LUCENE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437275#comment-16437275
]
Karl Wright commented on LUCENE-8251:
-
Unfortunately I need to deal with some other burning issues at the moment, and
I have no idea how to fix this particular problem either, so I'm going to have
to put it on hold until I think of something workable.
Next steps: First, validate the picture that the reason that the intersections
aren't getting detected is because they'd be off the ellipsoid.
> Test failure, geo3d complex polygons
>
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8251.jpg
>
>
> {code}
> Error Message:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]} Large polygon:
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1,
> address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}} Point: [lat=3.5E-323,
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5,
> Z=3.5E-323])] WKT: POLYGON((135.63207358036593
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593
> -51.43541696593334)) WKT: POINT(0.005183505059185348 1.98E-321) normal
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon:
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008,
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808,
> Z=-0.1286216320286114])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415,
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5,
> Z=-0.9182146655290553])], testPointInSet=true, shapes={
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051,
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888,
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484,
> Z=-0.7811731004355484])], [lat=-1.0294747773716673,
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546,
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791,
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597,
> Y=9.05
Re: When did we stop shipping changes.html?
We DO ship/distribute Changes.html, see http://www-us.apache.org/dist/lucene/solr/7.3.0/ in the changes folder But inside the tarball there is only an index.html file linking to the online versions, e.g. http://lucene.apache.org/solr/7_3_0/changes/Changes.html That was intentional. CHANGES.txt is still inside the tarball though. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 12. apr. 2018 kl. 22:37 skrev Cassandra Targett : > > I won’t speak for Jan and Uwe who worked on the patches there, but my feeling > is that it was specifically intended - the CHANGES entry for SOLR-9450 says > as much. > > Changes.html & associated files are built with the same ant target > (“documentation”) that builds javadocs. I think it was assumed that everyone > knew that (or would investigate if they had an interest), and would > understand that removing javadocs and replacing it with a single file would > also remove Changes.html from the /docs directory in the package. > > On Apr 12, 2018, at 3:15 PM, Alexandre Rafalovitch wrote: >> >> The scope of that JIRA was Javadocs specifically. >> >> Wouldn't loosing other files, such as changes.html be an unintended >> consequences then? >> >> Regards, >> Alex. >> >> On 12 April 2018 at 16:07, Cassandra Targett wrote: >>> I believe it was in 6.5, with >>> https://issues.apache.org/jira/browse/SOLR-9450. >>> >>> On Apr 12, 2018, at 2:45 PM, Alexandre Rafalovitch >>> wrote: >>> >>> The Solr's doc folder is suddenly looking scarily empty. >>> >>> Specifically, the changes.html now seems to be only online. That quite >>> surprised me. Not that I am in love with the current changes.txt or >>> changes.html for my usual use case (finding when something became >>> available), but still. >>> >>> Worse, I could not figure out when that changes.html file stopped >>> being shipped by trying to read or grep through changes.txt (catch-22) >>> or Jiras. >>> >>> Could somebody please point me to the relevant issue where that was >>> discussed and executed for more context. >>> >>> Regards, >>> Alex. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
