[jira] [Commented] (LUCENE-8243) IndexWriter might delete DV update files if addIndices are invovled
[
https://issues.apache.org/jira/browse/LUCENE-8243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430173#comment-16430173
]
ASF subversion and git services commented on LUCENE-8243:
-
Commit 7140e432594b67a8d6c93d6bf7ae2103717263ed in lucene-solr's branch
refs/heads/branch_7x from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7140e43 ]
LUCENE-8243: Add original finder to the attribution list in the CHANGES.TXT
> IndexWriter might delete DV update files if addIndices are invovled
> ---
>
> Key: LUCENE-8243
> URL: https://issues.apache.org/jira/browse/LUCENE-8243
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Michael McCandless
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8243.patch, LUCENE-8243.patch,
> broken_dv_update.patch
>
>
> the attached test fails with this output:
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/bin/java -ea
> -Djava.security.egd=file:/dev/./urandom
> -Didea.test.cyclic.buffer.size=1048576 -Dfile.encoding=UTF-8 -classpath
> "/Applications/IntelliJ
> IDEA.app/Contents/lib/idea_rt.jar:/Applications/IntelliJ
> IDEA.app/Contents/plugins/junit/lib/junit-rt.jar:/Applications/IntelliJ
> IDEA.app/Contents/plugins/junit/lib/junit5-rt.jar:/Users/simonw/projects/lucene-solr/idea-build/lucene/test-framework/classes/test:/Users/simonw/projects/lucene-solr/idea-build/lucene/test-framework/classes/java:/Users/simonw/projects/lucene-solr/lucene/test-framework/lib/junit-4.10.jar:/Users/simonw/projects/lucene-solr/lucene/test-framework/lib/randomizedtesting-runner-2.5.3.jar:/Users/simonw/projects/lucene-solr/idea-build/lucene/codecs/classes/java:/Users/simonw/projects/lucene-solr/idea-build/lucene/core/classes/java:/Users/simonw/projects/lucene-solr/idea-build/lucene/core/classes/test"
> com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 -junit4
> org.apache.lucene.index.TestAddIndexes,testAddIndexesDVUpdate
> IFD 0 [2018-04-06T19:27:27.176036Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> current segments file is "segments_1";
> deletionPolicy=org.apache.lucene.index.KeepOnlyLastCommitDeletionPolicy@27cf18f0
> IFD 0 [2018-04-06T19:27:27.188066Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> load commit "segments_1"
> IFD 0 [2018-04-06T19:27:27.189800Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> seg=_0 set nextWriteDelGen=2 vs current=1
> IFD 0 [2018-04-06T19:27:27.190053Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> removing unreferenced file "_0_1_Lucene70_0.dvd"
> IFD 0 [2018-04-06T19:27:27.190224Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> removing unreferenced file "_0_1.fnm"
> IFD 0 [2018-04-06T19:27:27.190371Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> removing unreferenced file "_0_1_Lucene70_0.dvm"
> IFD 0 [2018-04-06T19:27:27.190528Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: delete
> [_0_1_Lucene70_0.dvd, _0_1.fnm, _0_1_Lucene70_0.dvm]
> IFD 0 [2018-04-06T19:27:27.192558Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: now
> checkpoint "_0(8.0.0):C1:fieldInfosGen=1:dvGen=1" [1 segments ; isCommit =
> false]
> IFD 0 [2018-04-06T19:27:27.192806Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: 0 msec
> to checkpoint
> IW 0 [2018-04-06T19:27:27.193012Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> create=false
> IW 0 [2018-04-06T19:27:27.193428Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]:
> dir=MockDirectoryWrapper(RAMDirectory@79d3c690
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@795a0c8b)
> index=_0(8.0.0):C1:fieldInfosGen=1:dvGen=1
> version=8.0.0
> analyzer=org.apache.lucene.analysis.MockAnalyzer
> ramBufferSizeMB=16.0
> maxBufferedDocs=503
> mergedSegmentWarmer=null
> delPolicy=org.apache.lucene.index.KeepOnlyLastCommitDeletionPolicy
> commit=null
> openMode=CREATE_OR_APPEND
> similarity=org.apache.lucene.search.similarities.AssertingSimilarity
> mergeScheduler=org.apache.lucene.index.SerialMergeScheduler@2f3feff6
> codec=FastDecompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST_DECOMPRESSION,
> chunkSize=8, maxDocsPerChunk=6, blockSize=201),
> termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST_DECOMPRESSION,
> chunkSize=8, blockSize=201))
> infoStream=org.apache.lucene.util.PrintS
[jira] [Commented] (LUCENE-8243) IndexWriter might delete DV update files if addIndices are invovled
[
https://issues.apache.org/jira/browse/LUCENE-8243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430174#comment-16430174
]
ASF subversion and git services commented on LUCENE-8243:
-
Commit a49543b48aaec44c0735f6f41e6e455354720b9c in lucene-solr's branch
refs/heads/master from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a49543b ]
LUCENE-8243: Add original finder to the attribution list in the CHANGES.TXT
> IndexWriter might delete DV update files if addIndices are invovled
> ---
>
> Key: LUCENE-8243
> URL: https://issues.apache.org/jira/browse/LUCENE-8243
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Assignee: Michael McCandless
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8243.patch, LUCENE-8243.patch,
> broken_dv_update.patch
>
>
> the attached test fails with this output:
> {noformat}
> /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/bin/java -ea
> -Djava.security.egd=file:/dev/./urandom
> -Didea.test.cyclic.buffer.size=1048576 -Dfile.encoding=UTF-8 -classpath
> "/Applications/IntelliJ
> IDEA.app/Contents/lib/idea_rt.jar:/Applications/IntelliJ
> IDEA.app/Contents/plugins/junit/lib/junit-rt.jar:/Applications/IntelliJ
> IDEA.app/Contents/plugins/junit/lib/junit5-rt.jar:/Users/simonw/projects/lucene-solr/idea-build/lucene/test-framework/classes/test:/Users/simonw/projects/lucene-solr/idea-build/lucene/test-framework/classes/java:/Users/simonw/projects/lucene-solr/lucene/test-framework/lib/junit-4.10.jar:/Users/simonw/projects/lucene-solr/lucene/test-framework/lib/randomizedtesting-runner-2.5.3.jar:/Users/simonw/projects/lucene-solr/idea-build/lucene/codecs/classes/java:/Users/simonw/projects/lucene-solr/idea-build/lucene/core/classes/java:/Users/simonw/projects/lucene-solr/idea-build/lucene/core/classes/test"
> com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 -junit4
> org.apache.lucene.index.TestAddIndexes,testAddIndexesDVUpdate
> IFD 0 [2018-04-06T19:27:27.176036Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> current segments file is "segments_1";
> deletionPolicy=org.apache.lucene.index.KeepOnlyLastCommitDeletionPolicy@27cf18f0
> IFD 0 [2018-04-06T19:27:27.188066Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> load commit "segments_1"
> IFD 0 [2018-04-06T19:27:27.189800Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> seg=_0 set nextWriteDelGen=2 vs current=1
> IFD 0 [2018-04-06T19:27:27.190053Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> removing unreferenced file "_0_1_Lucene70_0.dvd"
> IFD 0 [2018-04-06T19:27:27.190224Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> removing unreferenced file "_0_1.fnm"
> IFD 0 [2018-04-06T19:27:27.190371Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> removing unreferenced file "_0_1_Lucene70_0.dvm"
> IFD 0 [2018-04-06T19:27:27.190528Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: delete
> [_0_1_Lucene70_0.dvd, _0_1.fnm, _0_1_Lucene70_0.dvm]
> IFD 0 [2018-04-06T19:27:27.192558Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: now
> checkpoint "_0(8.0.0):C1:fieldInfosGen=1:dvGen=1" [1 segments ; isCommit =
> false]
> IFD 0 [2018-04-06T19:27:27.192806Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: 0 msec
> to checkpoint
> IW 0 [2018-04-06T19:27:27.193012Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]: init:
> create=false
> IW 0 [2018-04-06T19:27:27.193428Z;
> TEST-TestAddIndexes.testAddIndexesDVUpdate-seed#[9F04EE6B720B6BFD]]:
> dir=MockDirectoryWrapper(RAMDirectory@79d3c690
> lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@795a0c8b)
> index=_0(8.0.0):C1:fieldInfosGen=1:dvGen=1
> version=8.0.0
> analyzer=org.apache.lucene.analysis.MockAnalyzer
> ramBufferSizeMB=16.0
> maxBufferedDocs=503
> mergedSegmentWarmer=null
> delPolicy=org.apache.lucene.index.KeepOnlyLastCommitDeletionPolicy
> commit=null
> openMode=CREATE_OR_APPEND
> similarity=org.apache.lucene.search.similarities.AssertingSimilarity
> mergeScheduler=org.apache.lucene.index.SerialMergeScheduler@2f3feff6
> codec=FastDecompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST_DECOMPRESSION,
> chunkSize=8, maxDocsPerChunk=6, blockSize=201),
> termVectorsFormat=CompressingTermVectorsFormat(compressionMode=FAST_DECOMPRESSION,
> chunkSize=8, blockSize=201))
> infoStream=org.apache.lucene.util.PrintStre
[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=16430185#comment-16430185
]
Karl Wright commented on LUCENE-8245:
-
This example has the opposite cause; instead of an edge crossing a bounding
plane but not being detected as crossing the main plane, something different is
happening. The reason I needed to broaden the envelope in the first place
beyond 1e-12 was because of numerical precision issues: sometimes we are
detecting that we're crossing both bounding planes when we really are crossing
just one, because of the precision of how we compute the intersection point.
I'll have to analyze this case numerically to see if there is a solution to how
we calculate this stuff. No chance of having time to look at it until midweek
or later.
> 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.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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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 # 7259 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7259/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 7 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: found:2[index.20180409073705460, index.20180409073706157, index.properties, replication.properties, snapshot_metadata] Stack Trace: java.lang.AssertionError: found:2[index.20180409073705460, index.20180409073706157, index.properties, replication.properties, snapshot_metadata] at __randomizedtesting.SeedInfo.seed([A15050B064F45937:7AFB507661DC3084]: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:966) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:937) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:913) 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.ThreadLeakCo
[jira] [Commented] (LUCENE-8222) TestICUTokenizerCJK failure
[
https://issues.apache.org/jira/browse/LUCENE-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430213#comment-16430213
]
Adrien Grand commented on LUCENE-8222:
--
Here is the bug report in the ICU bug tracker:
http://bugs.icu-project.org/trac/ticket/13669. I'll awaitfix
TestICUTokenizerCJK.
> TestICUTokenizerCJK failure
> ---
>
> Key: LUCENE-8222
> URL: https://issues.apache.org/jira/browse/LUCENE-8222
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Priority: Major
>
> This reproduces for me:
> {code:java}
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestICUTokenizerCJK
> -Dtests.method=testRandomHugeStrings -Dtests.seed=2C1F4414ECB02FE4
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=pl-PL
> -Dtests.timezone=Europe/Athens -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 0.57s | TestICUTokenizerCJK.testRandomHugeStrings <<<
> [junit4] > Throwable #1: org.junit.ComparisonFailure: term 128 expected:<ー[]>
> but was:<ー[デ]>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([2C1F4414ECB02FE4:B43C23D7B2C693AC]:0)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:201)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:325)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:329)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:869)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:668)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:566)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:479)
> [junit4] > at
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:107)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:844)
> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {dummy=PostingsFormat(name=LuceneVarGapDocFreqInterval)}, docValues:{},
> maxPointsInLeafNode=1800, maxMBSortInHeap=7.290162896982681,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@3f70f3d9),
> locale=pl-PL, timezone=Europe/Athens
> [junit4] 2> NOTE: Mac OS X 10.13.3 x86_64/Oracle Corporation 9.0.1
> (64-bit)/cpus=8,threads=1,free=150530048,total=268435456{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] (LUCENE-8222) TestICUTokenizerCJK failure
[
https://issues.apache.org/jira/browse/LUCENE-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430219#comment-16430219
]
ASF subversion and git services commented on LUCENE-8222:
-
Commit 8803bb5d844e4757c7ad5b8572fcaf2b2f4f21ab in lucene-solr's branch
refs/heads/branch_7x from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8803bb5 ]
LUCENE-8222: Await-fix TestICUTokenizerCJK.
> TestICUTokenizerCJK failure
> ---
>
> Key: LUCENE-8222
> URL: https://issues.apache.org/jira/browse/LUCENE-8222
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Priority: Major
>
> This reproduces for me:
> {code:java}
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestICUTokenizerCJK
> -Dtests.method=testRandomHugeStrings -Dtests.seed=2C1F4414ECB02FE4
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=pl-PL
> -Dtests.timezone=Europe/Athens -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 0.57s | TestICUTokenizerCJK.testRandomHugeStrings <<<
> [junit4] > Throwable #1: org.junit.ComparisonFailure: term 128 expected:<ー[]>
> but was:<ー[デ]>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([2C1F4414ECB02FE4:B43C23D7B2C693AC]:0)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:201)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:325)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:329)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:869)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:668)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:566)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:479)
> [junit4] > at
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:107)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:844)
> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {dummy=PostingsFormat(name=LuceneVarGapDocFreqInterval)}, docValues:{},
> maxPointsInLeafNode=1800, maxMBSortInHeap=7.290162896982681,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@3f70f3d9),
> locale=pl-PL, timezone=Europe/Athens
> [junit4] 2> NOTE: Mac OS X 10.13.3 x86_64/Oracle Corporation 9.0.1
> (64-bit)/cpus=8,threads=1,free=150530048,total=268435456{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] (LUCENE-8222) TestICUTokenizerCJK failure
[
https://issues.apache.org/jira/browse/LUCENE-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430220#comment-16430220
]
ASF subversion and git services commented on LUCENE-8222:
-
Commit 6568f3bb59877b063385e318400055fa1907bbc4 in lucene-solr's branch
refs/heads/master from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6568f3b ]
LUCENE-8222: Await-fix TestICUTokenizerCJK.
> TestICUTokenizerCJK failure
> ---
>
> Key: LUCENE-8222
> URL: https://issues.apache.org/jira/browse/LUCENE-8222
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Alan Woodward
>Priority: Major
>
> This reproduces for me:
> {code:java}
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestICUTokenizerCJK
> -Dtests.method=testRandomHugeStrings -Dtests.seed=2C1F4414ECB02FE4
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=pl-PL
> -Dtests.timezone=Europe/Athens -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 0.57s | TestICUTokenizerCJK.testRandomHugeStrings <<<
> [junit4] > Throwable #1: org.junit.ComparisonFailure: term 128 expected:<ー[]>
> but was:<ー[デ]>
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([2C1F4414ECB02FE4:B43C23D7B2C693AC]:0)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:201)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:325)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:329)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:869)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:668)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:566)
> [junit4] > at
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:479)
> [junit4] > at
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:107)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:844)
> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70):
> {dummy=PostingsFormat(name=LuceneVarGapDocFreqInterval)}, docValues:{},
> maxPointsInLeafNode=1800, maxMBSortInHeap=7.290162896982681,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@3f70f3d9),
> locale=pl-PL, timezone=Europe/Athens
> [junit4] 2> NOTE: Mac OS X 10.13.3 x86_64/Oracle Corporation 9.0.1
> (64-bit)/cpus=8,threads=1,free=150530048,total=268435456{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] (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=16430223#comment-16430223
]
Karl Wright commented on LUCENE-8245:
-
Turned on diagnostic output for this case. Here it is:
{code}
[junit4] 1> Considering edge [lat=-0.6183600459696781,
lon=-2.770488856855538([X=-0.7593628058597481, Y=-0.29549354861758625,
Z=-0.5796996565482825])] -> [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342,
Y=-0.11274773940940182, Z=-0.9927936672533157])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1>
[junit4] 1> Edge added 2 to innerCrossingCount
[junit4] 1> Edge added 1 to outerCrossingCount
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1>
[junit4] 1> Edge added 1 to innerCrossingCount
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
> 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.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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-ma
[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=16430235#comment-16430235
]
Karl Wright commented on LUCENE-8245:
-
Reformatted, for easier reading:
{code}
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-0.6183600459696781,
lon=-2.770488856855538([X=-0.7593628058597481, Y=-0.29549354861758625,
Z=-0.5796996565482825])] -> [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Travel inner point [X=1.0, Y=-1.336807223683658E-12,
Z=-1.1771178322187736E-11]
[junit4] 1> Test point inner point [X=0.7540698997149413,
Y=-0.07411317803504912, Z=-0.6525992822440454]
[junit4] 1> Edge added 2 to innerCrossingCount
[junit4] 1> Test point outer point [X=0.7540698997131706,
Y=-0.07411317803527853, Z=-0.6525992822460656]
[junit4] 1> Edge added 1 to outerCrossingCount
[junit4] 1>
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> Travel inner point [X=1.0, Y=-1.3368072236836578E-12,
Z=2.920754816285907E-13]
[junit4] 1> Edge added 1 to innerCrossingCount
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
As you can see, there's one edge that adds TWO inner crossings and one outer
crossing. Quite a feat. Figuring out how it does that is the trick.
> 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.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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-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=16430223#comment-16430223
]
Karl Wright edited comment on LUCENE-8245 at 4/9/18 8:00 AM:
-
Turned on diagnostic output for this case. Here it is:
{code}
[junit4] 1> Considering edge [lat=-0.6183600459696781,
lon=-2.770488856855538([X=-0.7593628058597481, Y=-0.29549354861758625,
Z=-0.5796996565482825])] -> [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342,
Y=-0.11274773940940182, Z=-0.9927936672533157])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1>
[junit4] 1> Travel inner point [X=1.0, Y=-1.336807223683658E-12,
Z=-1.1771178322187736E-11]
[junit4] 1> Test point inner point [X=0.7540698997149413,
Y=-0.07411317803504912, Z=-0.6525992822440454]
[junit4] 1> Edge added 2 to innerCrossingCount
[junit4] 1> Test point outer point [X=0.7540698997131706,
Y=-0.07411317803527853, Z=-0.6525992822460656]
[junit4] 1> Edge added 1 to outerCrossingCount
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1>
[junit4] 1> Travel inner point [X=1.0, Y=-1.3368072236836578E-12,
Z=2.920754816285907E-13]
[junit4] 1> Edge added 1 to innerCrossingCount
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
was (Author: kwri...@metacarta.com):
Turned on diagnostic output for this case. Here it is:
{code}
[junit4] 1> Considering edge [lat=-0.6183600459696781,
lon=-2.770488856855538([X=-0.7593628058597481, Y=-0.29549354861758625,
Z=-0.5796996565482825])] -> [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342,
Y=-0.11274773940940182, Z=-0.9927936672533157])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> Test point plane: [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4
TestPerFieldDocValuesFormat timeout
There is an odd timeout failure here: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/195/consoleFull The TestPerFieldDocValuesFormat timed out. The stack trace shows just one relevant thread in the enforced index merge, never returning from the loop awaiting the number of segments to reach the desired number. Is it possible that the merge policy ignores MergeTrigger.EXPLICIT this this results in an endless loop? [junit4] 2>4) Thread[id=12, name=TEST-TestPerFieldDocValuesFormat.testSparseBinaryFixedLengthVsStoredFields-seed#[617399315453E295], state=TIMED_WAITING, group=TGRP-TestPerFieldDocValuesFormat] [junit4] 2> at java.lang.Object.wait(Native Method) [junit4] 2> at org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4716) [junit4] 2> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2191) [junit4] 2> at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2119) [junit4] 2> at org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:445) [junit4] 2> at org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestBinaryVsStoredFields(BaseDocValuesFormatTestCase.java:1472) [junit4] 2> at org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestBinaryFixedLengthVsStoredFields(BaseDocValuesFormatTestCase.java:1508) [junit4] 2> at org.apache.lucene.index.BaseDocValuesFormatTestCase.testSparseBinaryFixedLengthVsStoredFields(BaseDocValuesFormatTestCase.java:1501) Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #345: LUCENE-8229: Add Weight.matches() method
Github user jpountz commented on the issue: https://github.com/apache/lucene-solr/pull/345 Can we also check that it returns null on non-matching documents? --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12200) ZkControllerTest failure. Leaking Overseer
[ https://issues.apache.org/jira/browse/SOLR-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-12200: Attachment: tests-failures.txt > 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#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 # 196 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/196/ No tests ran. Build Log: [...truncated 23775 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 2178 links (1735 relative) to 2887 anchors in 227 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-12200) ZkControllerTest failure. Leaking Overseer
[ https://issues.apache.org/jira/browse/SOLR-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430272#comment-16430272 ] Mikhail Khludnev commented on SOLR-12200: - beasting hard yields [^tests-failures.txt]. It seems like the same leak/exception, however we can see that horrible multimegs exception spin doesn't occur at OverseerTriggerThread anymore. > 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#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (SOLR-9640) Support PKI authentication and SSL in standalone-mode master/slave auth with local security.json
Hi,
Looks like the auto Patch validation tests run @BadApple tests?
> Failed junit tests | solr.cloud.TestLeaderElectionZkExpiry
The test was bad-appled in March
> @Test
> @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";) //
> 17-Mar-2018
> public void testLeaderElectionWithZkExpiry() throws Exception {
Is this on purpose?
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 9. apr. 2018 kl. 07:26 skrev Lucene/Solr QA (JIRA) :
>
>
>[
> https://issues.apache.org/jira/browse/SOLR-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430036#comment-16430036
> ]
>
> Lucene/Solr QA commented on SOLR-9640:
> --
>
> | (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
> 16s{color} | {color:green} master passed {color} |
> || || || || {color:brown} Patch Compile Tests {color} ||
> | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
> 13s{color} | {color:green} the patch passed {color} |
> | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
> 13s{color} | {color:green} the patch passed {color} |
> | {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
> {color:green} 1m 9s{color} | {color:green} the patch passed {color} |
> | {color:red}-1{color} | {color:red} Check forbidden APIs {color} |
> {color:red} 1m 6s{color} | {color:red} Check forbidden APIs
> check-forbidden-apis failed {color} |
> | {color:red}-1{color} | {color:red} Validate source patterns {color} |
> {color:red} 1m 6s{color} | {color:red} Check forbidden APIs
> check-forbidden-apis failed {color} |
> || || || || {color:brown} Other Tests {color} ||
> | {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m
> 32s{color} | {color:red} core in the patch failed. {color} |
> | {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
> 19s{color} | {color:green} test-framework in the patch passed. {color} |
> | {color:black}{color} | {color:black} {color} | {color:black} 56m 59s{color}
> | {color:black} {color} |
> \\
> \\
> || Reason || Tests ||
> | Failed junit tests | solr.cloud.TestLeaderElectionZkExpiry |
> \\
> \\
> || Subsystem || Report/Notes ||
> | JIRA Issue | SOLR-9640 |
> | JIRA Patch URL |
> https://issues.apache.org/jira/secure/attachment/12917997/SOLR-9640.patch |
> | Optional Tests | compile javac unit ratsources checkforbiddenapis
> validatesourcepatterns |
> | uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8
> 21:10:42 UTC 2016 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 / 3530397 |
> | ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
> | Default Java | 1.8.0_152 |
> | Check forbidden APIs |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-check-forbidden-apis-solr.txt
> |
> | Validate source patterns |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-check-forbidden-apis-solr.txt
> |
> | unit |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-unit-solr_core.txt
> |
> | Test Results |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/testReport/ |
> | modules | C: solr solr/core solr/test-framework U: solr |
> | Console output |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/console |
> | Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
>
>
> This message was automatically generated.
>
>
>
>> Support PKI authentication and SSL in standalone-mode master/slave auth with
>> local security.json
>>
>>
>>Key: SOLR-9640
>>URL: https://issues.apache.org/jira/browse/SOLR-9640
>>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
>> Labels: authentication, pki
>>Fix For: 7.4, master (8.0)
>>
>>Attachments: SOLR-9640.patch, SOLR-9640.patch, SOLR-9640.patch,
>> SOLR-9640.patch, SOLR-9640.patch, SOLR-9640.patch, SOLR-9640.patch,
>> SOLR-9640.patch
>>
>> Time Spent
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.4) - Build # 536 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/536/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 6 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: found:2[index.20180409131019950, index.20180409131020317, index.properties, replication.properties, snapshot_metadata] Stack Trace: java.lang.AssertionError: found:2[index.20180409131019950, index.20180409131020317, index.properties, replication.properties, snapshot_metadata] at __randomizedtesting.SeedInfo.seed([EF0FA19B31D1:34AD66A9A4B35862]: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:966) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:937) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:913) 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.ThreadLeakContro
[GitHub] lucene-solr issue #345: LUCENE-8229: Add Weight.matches() method
Github user romseygeek commented on the issue: https://github.com/apache/lucene-solr/pull/345 I extended MatchesAsserter to keep track of the last matching document, and check that if the document one below the current collection is not a hit, then its Matches is null. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (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:all-tabpanel
]
Ignacio Vera updated LUCENE-8245:
-
Attachment: LUCENE-8245.jpg
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-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=16430311#comment-16430311
]
Ignacio Vera commented on LUCENE-8245:
--
Attached a visual representation of the shape and travel planes.
I think the problem is the edge that adds an inner and an outer plane, it
should only add one!
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-8237) Add a SoftDeletesDirectoryReaderWrapper
[ https://issues.apache.org/jira/browse/LUCENE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430325#comment-16430325 ] ASF subversion and git services commented on LUCENE-8237: - Commit ed62b990d8bfa61eefd918cfdfc82e5848afa5dd in lucene-solr's branch refs/heads/master from [~simonw] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ed62b99 ] LUCENE-8237: Add a SoftDeletesDirectoryReaderWrapper This adds support for soft deletes if the reader is opened form a directory. Today we only support soft deletes for NRT readers, this change allows to wrap existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also filter out soft deletes in the case of a non-NRT reader. > Add a SoftDeletesDirectoryReaderWrapper > > > Key: LUCENE-8237 > URL: https://issues.apache.org/jira/browse/LUCENE-8237 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8237.patch > > > This adds support for soft deletes if the reader is opened form a directory. > Today we only support soft deletes for NRT readers, this change allows to wrap > existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also > filter > out soft deletes in the case of a non-NRT reader. -- 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-8237) Add a SoftDeletesDirectoryReaderWrapper
[ https://issues.apache.org/jira/browse/LUCENE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-8237: Attachment: LUCENE-8237.patch > Add a SoftDeletesDirectoryReaderWrapper > > > Key: LUCENE-8237 > URL: https://issues.apache.org/jira/browse/LUCENE-8237 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8237.patch, LUCENE-8237.patch > > > This adds support for soft deletes if the reader is opened form a directory. > Today we only support soft deletes for NRT readers, this change allows to wrap > existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also > filter > out soft deletes in the case of a non-NRT reader. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 196 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/196/ 5 tests failed. FAILED: org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention Error Message: GC overhead limit exceeded Stack Trace: java.lang.OutOfMemoryError: GC overhead limit exceeded at __randomizedtesting.SeedInfo.seed([248C95A59BE17434:3432A38A78701E91]:0) at java.util.HashMap$KeySet.iterator(HashMap.java:917) at java.util.HashSet.iterator(HashSet.java:173) at org.apache.lucene.index.IndexWriter.maxNumSegmentsMergesPending(IndexWriter.java:2216) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2190) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2119) at org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention(TestSoftDeletesRetentionMergePolicy.java:266) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy Error Message: 2 threads leaked from SUITE scope at org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy: 1) Thread[id=289762, name=Lucene Merge Thread #281215, state=RUNNABLE, group=TGRP-TestSoftDeletesRetentionMergePolicy] at java.lang.Thread.yield(Native Method) at org.apache.lucene.store.MockDirectoryWrapper.maybeYield(MockDirectoryWrapper.java:626) at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:644) at org.apache.lucene.store.LockValidatingDirectoryWrapper.createOutput(LockValidatingDirectoryWrapper.java:44) at org.apache.lucene.index.ConcurrentMergeScheduler$1.createOutput(ConcurrentMergeScheduler.java:288) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:43) at org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.finish(Lucene60PointsWriter.java:243) at org.apache.lucene.codecs.PointsWriter.merge(PointsWriter.java:189) at org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.merge(Lucene60PointsWriter.java:144) at org.apache.lucene.index.SegmentMerger.mergePoints(SegmentMerger.java:187) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:136
[jira] [Commented] (LUCENE-8237) Add a SoftDeletesDirectoryReaderWrapper
[ https://issues.apache.org/jira/browse/LUCENE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430336#comment-16430336 ] ASF subversion and git services commented on LUCENE-8237: - Commit b7a6a25883be622217ecbe2edd3b20a9106efc94 in lucene-solr's branch refs/heads/branch_7x from [~simonw] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b7a6a25 ] LUCENE-8237: Add a SoftDeletesDirectoryReaderWrapper This adds support for soft deletes if the reader is opened form a directory. Today we only support soft deletes for NRT readers, this change allows to wrap existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also filter out soft deletes in the case of a non-NRT reader. > Add a SoftDeletesDirectoryReaderWrapper > > > Key: LUCENE-8237 > URL: https://issues.apache.org/jira/browse/LUCENE-8237 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8237.patch, LUCENE-8237.patch > > > This adds support for soft deletes if the reader is opened form a directory. > Today we only support soft deletes for NRT readers, this change allows to wrap > existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also > filter > out soft deletes in the case of a non-NRT reader. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8237) Add a SoftDeletesDirectoryReaderWrapper
[ https://issues.apache.org/jira/browse/LUCENE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-8237. - Resolution: Fixed fixed > Add a SoftDeletesDirectoryReaderWrapper > > > Key: LUCENE-8237 > URL: https://issues.apache.org/jira/browse/LUCENE-8237 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8237.patch, LUCENE-8237.patch > > > This adds support for soft deletes if the reader is opened form a directory. > Today we only support soft deletes for NRT readers, this change allows to wrap > existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also > filter > out soft deletes in the case of a non-NRT reader. -- 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-8237) Add a SoftDeletesDirectoryReaderWrapper
[ https://issues.apache.org/jira/browse/LUCENE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430338#comment-16430338 ] ASF subversion and git services commented on LUCENE-8237: - Commit 918ecb84ccec02ad29af6fbbe6ed406c8fb557ad in lucene-solr's branch refs/heads/branch_7x from [~simonw] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=918ecb8 ] LUCENE-8237: Add missing CHANGES.TXT entry > Add a SoftDeletesDirectoryReaderWrapper > > > Key: LUCENE-8237 > URL: https://issues.apache.org/jira/browse/LUCENE-8237 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8237.patch, LUCENE-8237.patch > > > This adds support for soft deletes if the reader is opened form a directory. > Today we only support soft deletes for NRT readers, this change allows to wrap > existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also > filter > out soft deletes in the case of a non-NRT reader. -- 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-8237) Add a SoftDeletesDirectoryReaderWrapper
[ https://issues.apache.org/jira/browse/LUCENE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430339#comment-16430339 ] ASF subversion and git services commented on LUCENE-8237: - Commit a7a3c0a282978074b03d8855774ba0287f6ba810 in lucene-solr's branch refs/heads/master from [~simonw] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a7a3c0a ] LUCENE-8237: Add missing CHANGES.TXT entry > Add a SoftDeletesDirectoryReaderWrapper > > > Key: LUCENE-8237 > URL: https://issues.apache.org/jira/browse/LUCENE-8237 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8237.patch, LUCENE-8237.patch > > > This adds support for soft deletes if the reader is opened form a directory. > Today we only support soft deletes for NRT readers, this change allows to wrap > existing DirectoryReader with a SoftDeletesDirectoryReaderWrapper to also > filter > out soft deletes in the case of a non-NRT reader. -- 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: [JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 196 - Failure
I am looking into this On Mon, Apr 9, 2018 at 12:06 PM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/196/ > > 5 tests failed. > FAILED: > org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention > > Error Message: > GC overhead limit exceeded > > Stack Trace: > java.lang.OutOfMemoryError: GC overhead limit exceeded > at > __randomizedtesting.SeedInfo.seed([248C95A59BE17434:3432A38A78701E91]:0) > at java.util.HashMap$KeySet.iterator(HashMap.java:917) > at java.util.HashSet.iterator(HashSet.java:173) > at > org.apache.lucene.index.IndexWriter.maxNumSegmentsMergesPending(IndexWriter.java:2216) > at > org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2190) > at > org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2119) > at > org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention(TestSoftDeletesRetentionMergePolicy.java:266) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > FAILED: > junit.framework.TestSuite.org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy > > Error Message: > 2 threads leaked from SUITE scope at > org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy: 1) > Thread[id=289762, name=Lucene Merge Thread #281215, state=RUNNABLE, > group=TGRP-TestSoftDeletesRetentionMergePolicy] at > java.lang.Thread.yield(Native Method) at > org.apache.lucene.store.MockDirectoryWrapper.maybeYield(MockDirectoryWrapper.java:626) > at > org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:644) > at > org.apache.lucene.store.LockValidatingDirectoryWrapper.createOutput(LockValidatingDirectoryWrapper.java:44) > at > org.apache.lucene.index.ConcurrentMergeScheduler$1.createOutput(ConcurrentMergeScheduler.java:288) > at > org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:43) > at > org.apache.lucene.codecs.lucene60.Lucene60PointsWriter.finish(Lucene60PointsWriter.java:243) > at > org.apache.lucene.codecs.PointsWriter.merge(PointsWriter.ja
[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=16430353#comment-16430353
]
Karl Wright commented on LUCENE-8245:
-
Basic on the graphic, there should be two adjoining edges intersect the travel
plane. But the total inner crossings, added together, should be equal - same
number of inner crossings as outer crossings. We're seeing only ONE come up as
intersecting the travel plane, though. That's hard to do given that the other
crosses it.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-12131) Authorization plugin support for getting user's roles from the outside
[
https://issues.apache.org/jira/browse/SOLR-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430358#comment-16430358
]
Jan Høydahl commented on SOLR-12131:
Appreciate feedback on this from [~noble.paul], [~anshum].
Especially the means of transferring list of user roles from Auth plugin to
Authorization plugin as part of the {{Principal}} object. Other ways to
transfer the roles could be
* add a new {{userRoles}} member in {{AuthorizationContext}}
* add a threadLocal variable on the request thread
What do you think?
I hope to commit this new plugin soon.
> Authorization plugin support for getting user's roles from the outside
> --
>
> Key: SOLR-12131
> URL: https://issues.apache.org/jira/browse/SOLR-12131
> 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
> Fix For: 7.4, master (8.0)
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the {{RuleBasedAuthorizationPlugin}} relies on explicitly mapping
> users to roles. However, when users are authenticated by an external Identity
> service (e.g. JWT as implemented in SOLR-12121), that external service keeps
> track of the user's roles, and will pass that as a "claim" in the token (JWT).
> In order for Solr to be able to Authorise requests based on those roles, the
> Authorization plugin should be able to accept (verified) roles from the
> request instead of explicit mapping.
> Suggested approach is to create a new interface {{VerifiedUserRoles}} and a
> {{PrincipalWithUserRoles}} which implements the interface. The Authorization
> plugin can then pull the roles from request. By piggy-backing on the
> Principal, we have a seamless way to transfer extra external information, and
> there is also a natural relationship:
> {code:java}
> User Authentication -> Role validation -> Creating a Principal{code}
> I plan to add the interface, the custom Principal class and restructure
> {{RuleBasedAuthorizationPlugin}} in an abstract base class and two
> implementations: {{RuleBasedAuthorizationPlugin}} (as today) and a new
> {{ExternalRoleRuleBasedAuthorizationPlugin.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4557 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4557/ Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations Error Message: No off-plane intersection points were found; can't compute traversal Stack Trace: java.lang.IllegalArgumentException: No off-plane intersection points were found; can't compute traversal at __randomizedtesting.SeedInfo.seed([7BAAE36CC3CC7C16:CBD59EF84C81D28A]:0) at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.pickProximate(GeoComplexPolygon.java:1201) at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.computeInsideOutside(GeoComplexPolygon.java:1181) at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.matches(GeoComplexPolygon.java:1254) at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Node.traverse(GeoComplexPolygon.java:664) at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:760) at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:746) at org.apache.lucene.spatial3d.geom.GeoComplexPolygon.isWithin(GeoComplexPolygon.java:456) at org.apache.lucene.spatial3d.geom.GeoBaseMembershipShape.isWithin(GeoBaseMembershipShape.java:36) at org.apache.lucene.spatial3d.geom.BaseXYZSolid.isAreaInsideShape(BaseXYZSolid.java:130) at org.apache.lucene.spatial3d.geom.StandardXYZSolid.getRelationship(StandardXYZSolid.java:432) at org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations(TestGeo3DPoint.java:311) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(T
[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=16430353#comment-16430353
]
Karl Wright edited comment on LUCENE-8245 at 4/9/18 11:06 AM:
--
What's right:
The graphic shows there are only two edges that intersect the travel plane and
test point plane. And we find two, which is good. These are the ones we find:
{code}
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
{code}
and
{code}
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
{code}
We'd expect one of the planes to intersect both the travel and the test point
planes, and the other to intersect just one. The second edge intersects just
the travel plane, and it crosses both inner and outer envelopes. The first
edge, therefore, should cross the test point plane, both inner and outer, and
it does. But since the second edge crossed both inner and outer travel plane
envelopes, we'd expect that the first edge would do the same, but it doesn't;
it only crosses the inner side.
So, either, the first edge should also cross the outer side of the travel
plane, or the second edge should NOT cross the outer side of the travel plane.
We need to determine what the right behavior is by going deeper numerically --
we need to evaluate the edge endpoint to see where it sits relative to the
travel plane and to the inner and outer envelopes. I will add evaluate()
method calls to the diagnostics so we can see this.
But it's also clear we're looking at a numerical precision problem here.
was (Author: kwri...@metacarta.com):
Basic on the graphic, there should be two adjoining edges intersect the travel
plane. But the total inner crossings, added together, should be equal - same
number of inner crossings as outer crossings. We're seeing only ONE come up as
intersecting the travel plane, though. That's hard to do given that the other
crosses it.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-12096) Inconsistent response format in subquery transform
[
https://issues.apache.org/jira/browse/SOLR-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430372#comment-16430372
]
ASF subversion and git services commented on SOLR-12096:
Commit ea08bd3b67ff6b35d6264054d2131a87bbe9b870 in lucene-solr's branch
refs/heads/master from [~ishan1604]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ea08bd3 ]
SOLR-12096: Fixed inconsistent results format of subquery transformer for
distributed search (multi-shard)
> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch,
> SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.testsubquery.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared
> to single-shard
> h1. Single Shard collection
> Request
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10001677",
> "score": 0.5,
> "_children_": {
> "numFound": 9,
> "start": 0,
> "docs": [
> {
> "uniqueId": "100016771",
> "score": 0.5
> },
> {
> "uniqueId": "100016772",
> "score": 0.5
> },
> {
> "uniqueId": "100016773",
> "score": 0.5
> }
> ]
> }
> }
> ]
> }
> }
> {code}
> Here, *_children_* suquery response is as expected (Based on documentation)
> h1. Multi Shard collection(2)
> Request
> {code:java}
> localhost:8983/solr/k_test_2/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 11,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
>
[jira] [Commented] (SOLR-12096) Inconsistent response format in subquery transform
[
https://issues.apache.org/jira/browse/SOLR-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430373#comment-16430373
]
ASF subversion and git services commented on SOLR-12096:
Commit 91bd3e1f1febf1d0953186be8cbc9b4e2146e579 in lucene-solr's branch
refs/heads/branch_7x from [~ishan1604]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=91bd3e1 ]
SOLR-12096: Fixed inconsistent results format of subquery transformer for
distributed search (multi-shard)
> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch,
> SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.testsubquery.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared
> to single-shard
> h1. Single Shard collection
> Request
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10001677",
> "score": 0.5,
> "_children_": {
> "numFound": 9,
> "start": 0,
> "docs": [
> {
> "uniqueId": "100016771",
> "score": 0.5
> },
> {
> "uniqueId": "100016772",
> "score": 0.5
> },
> {
> "uniqueId": "100016773",
> "score": 0.5
> }
> ]
> }
> }
> ]
> }
> }
> {code}
> Here, *_children_* suquery response is as expected (Based on documentation)
> h1. Multi Shard collection(2)
> Request
> {code:java}
> localhost:8983/solr/k_test_2/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 11,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
>
[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=16430401#comment-16430401
]
Ignacio Vera commented on LUCENE-8245:
--
I checked the intersection point of the top edge with the travel plane and it
is numerically identical to the edge start point and still contributes with an
inner and outer crossing.
Maybe this idea is too naive but if we calculate all intersection points we can
assume the following:
1) if the intersection point is not numericaly identical to start and end
edges, then it should contribute with an inner and an outer crossing. (we don't
really need to calculate the crossings)
2) if the intersection point is numericaly identical to start or end edges,
then it should contribute with just an inner or an outer crossing. (we just
need to find out how to choose one...)
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-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=16430409#comment-16430409
]
Karl Wright commented on LUCENE-8245:
-
Here's the revised output for these two edges:
{code}
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> start point travel dist=-0.11274773940907501; end point
travel dist=3.268072236836579E-13
[junit4] 1> start point travel above dist=-0.11274773940806501; end point
travel above dist=1.336807223683658E-12
[junit4] 1> start point travel below dist=-0.11274773941008501; end point
travel below dist=-6.831927763163422E-13
[junit4] 1> start point testpoint dist=-0.34019438500826027; end point
testpoint dist=0.6525992822450555
[junit4] 1> start point testpoint above dist=-0.3401943850072502; end
point testpoint above dist=0.6525992822460656
[junit4] 1> start point testpoint below dist=-0.34019438500927035; end
point testpoint below dist=0.6525992822440454
[junit4] 1> Travel inner point [X=1.0, Y=-1.336807223683658E-12,
Z=-1.1771178322187736E-11]
[junit4] 1> Test point inner point [X=0.7540698997149413,
Y=-0.07411317803504912, Z=-0.6525992822440454]
[junit4] 1> Edge added 2 to innerCrossingCount
[junit4] 1> Test point outer point [X=0.7540698997131706,
Y=-0.07411317803527853, Z=-0.6525992822460656]
[junit4] 1> Edge added 1 to outerCrossingCount
[junit4] 1>
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> start point travel dist=3.268072236836579E-13; end point
travel dist=-0.6365576248358092
[junit4] 1> start point travel above dist=1.336807223683658E-12; end
point travel above dist=-0.6365576248347993
[junit4] 1> start point travel below dist=-6.831927763163422E-13; end
point travel below dist=-0.6365576248368193
[junit4] 1> start point testpoint dist=0.6525992822450555; end point
testpoint dist=0.7916790774200425
[junit4] 1> start point testpoint above dist=0.6525992822460656; end
point testpoint above dist=0.7916790774210526
[junit4] 1> start point testpoint below dist=0.6525992822440454; end
point testpoint below dist=0.7916790774190324
[junit4] 1> Travel inner point [X=1.0, Y=-1.3368072236836578E-12,
Z=2.920754816285907E-13]
[junit4] 1> Edge added 1 to innerCrossingCount
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
The first edge's endpoint is on the "below" travel plane, but not the "above"
one, and that's of course true as well for the start point of the second edge,
since they're shared. And indeed we see two "inner" crossings of the travel
plane -- one from each edge. Those are correct.
So we're seeing an extra crossing of the outer plane that we should not,
specifically this one:
{code}
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
We compute this by calling Plane.findCrossings() between the travel plane and
the edge plane, with the computed bounds planes. We should not find this
intersection, but we do anyway.
The numeric precision of that method under these conditions is not adequate to
this kind of find-grained envelope computation. The next step is to see
whether the point that it finds is off the two intersecting planes, and if so,
by how much. If that's what is going wrong, we may need to increase
MINIMUM_RESOLUTION somewhat to cover the computation issues, maybe to 2e-12.
OR we can try a successive approximation approach to the intersection math --
but I don't relish that idea, frankly.
> 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
>
[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=16430409#comment-16430409
]
Karl Wright edited comment on LUCENE-8245 at 4/9/18 11:38 AM:
--
Here's the revised output for these two edges:
{code}
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> start point travel dist=-0.11274773940907501; end point
travel dist=3.268072236836579E-13
[junit4] 1> start point travel above dist=-0.11274773940806501; end point
travel above dist=1.336807223683658E-12
[junit4] 1> start point travel below dist=-0.11274773941008501; end point
travel below dist=-6.831927763163422E-13
[junit4] 1> start point testpoint dist=-0.34019438500826027; end point
testpoint dist=0.6525992822450555
[junit4] 1> start point testpoint above dist=-0.3401943850072502; end
point testpoint above dist=0.6525992822460656
[junit4] 1> start point testpoint below dist=-0.34019438500927035; end
point testpoint below dist=0.6525992822440454
[junit4] 1> Travel inner point [X=1.0, Y=-1.336807223683658E-12,
Z=-1.1771178322187736E-11]
[junit4] 1> Test point inner point [X=0.7540698997149413,
Y=-0.07411317803504912, Z=-0.6525992822440454]
[junit4] 1> Edge added 2 to innerCrossingCount
[junit4] 1> Test point outer point [X=0.7540698997131706,
Y=-0.07411317803527853, Z=-0.6525992822460656]
[junit4] 1> Edge added 1 to outerCrossingCount
[junit4] 1>
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> start point travel dist=3.268072236836579E-13; end point
travel dist=-0.6365576248358092
[junit4] 1> start point travel above dist=1.336807223683658E-12; end
point travel above dist=-0.6365576248347993
[junit4] 1> start point travel below dist=-6.831927763163422E-13; end
point travel below dist=-0.6365576248368193
[junit4] 1> start point testpoint dist=0.6525992822450555; end point
testpoint dist=0.7916790774200425
[junit4] 1> start point testpoint above dist=0.6525992822460656; end
point testpoint above dist=0.7916790774210526
[junit4] 1> start point testpoint below dist=0.6525992822440454; end
point testpoint below dist=0.7916790774190324
[junit4] 1> Travel inner point [X=1.0, Y=-1.3368072236836578E-12,
Z=2.920754816285907E-13]
[junit4] 1> Edge added 1 to innerCrossingCount
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
The first edge's endpoint is on the "below" travel plane, but not the "above"
one, and that's of course true as well for the start point of the second edge,
since they're shared. And indeed we see two "inner" crossings of the travel
plane -- one from each edge. Those are correct.
So we're seeing an extra crossing of the outer plane that we should not,
specifically this one:
{code}
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
We compute this by calling Plane.findCrossings() between the outer travel plane
and the edge plane, within the computed bounds planes. We should not find this
intersection, but we do anyway, and that is the cause of the problem.
The numeric precision of that method under these conditions is not adequate to
this kind of find-grained envelope computation. The next step is to see
whether the point that it finds is off the two intersecting planes, and if so,
by how much. If that's what is going wrong, we may need to increase
MINIMUM_RESOLUTION somewhat to cover the computation issues, maybe to 2e-12.
OR we can try a successive approximation approach to the intersection math --
but I don't relish that idea, frankly.
was (Author: kwri...@metacarta.com):
Here's the revised output for these two edges:
{code}
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> start point travel dist=-0.11274773940907501; end point
travel dist=3.268072236836579E-13
[junit4] 1> start point travel above dist=-0.11274773940806501; end point
travel above dist=1.336807223683658E-12
[j
Re: lucene-solr:branch_7x: SOLR-12096: Fixed inconsistent results format of subquery transformer for distributed search (multi-shard)
Hey Ishan, I think you inadvertently committed the patch file as well?
> On 9 Apr 2018, at 12:07, is...@apache.org wrote:
>
> Repository: lucene-solr
> Updated Branches:
> refs/heads/branch_7x 918ecb84c -> 91bd3e1f1
>
>
> SOLR-12096: Fixed inconsistent results format of subquery transformer for
> distributed search (multi-shard)
>
>
> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/91bd3e1f
> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/91bd3e1f
> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/91bd3e1f
>
> Branch: refs/heads/branch_7x
> Commit: 91bd3e1f1febf1d0953186be8cbc9b4e2146e579
> Parents: 918ecb8
> Author: Ishan Chattopadhyaya
> Authored: Mon Apr 9 16:36:07 2018 +0530
> Committer: Ishan Chattopadhyaya
> Committed: Mon Apr 9 16:36:49 2018 +0530
>
> --
> SOLR-12096.patch| 217 +++
> solr/CHANGES.txt| 3 +
> .../solr/response/GeoJSONResponseWriter.java| 3 +-
> .../solr/response/JSONResponseWriter.java | 6 +-
> .../apache/solr/response/JSONWriterTest.java| 24 +-
> .../TestSubQueryTransformerDistrib.java | 59 +++--
> 6 files changed, 289 insertions(+), 23 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/91bd3e1f/SOLR-12096.patch
> --
> diff --git a/SOLR-12096.patch b/SOLR-12096.patch
> new file mode 100644
> index 000..9ed1ad7
> --- /dev/null
> +++ b/SOLR-12096.patch
> @@ -0,0 +1,217 @@
> +diff --git
> a/solr/core/src/java/org/apache/solr/response/GeoJSONResponseWriter.java
> b/solr/core/src/java/org/apache/solr/response/GeoJSONResponseWriter.java
> +index 43fd7b4..012290e 100644
> +--- a/solr/core/src/java/org/apache/solr/response/GeoJSONResponseWriter.java
> b/solr/core/src/java/org/apache/solr/response/GeoJSONResponseWriter.java
> +@@ -166,7 +166,8 @@ class GeoJSONWriter extends JSONWriter {
> +
> + // SolrDocument will now have multiValued fields represented as a
> Collection,
> + // even if only a single value is returned for this document.
> +- if (val instanceof List) {
> ++ // For SolrDocumentList, use writeVal instead of writeArray
> ++ if (!(val instanceof SolrDocumentList) && val instanceof List) {
> + // shortcut this common case instead of going through writeVal again
> + writeArray(name,((Iterable)val).iterator());
> + } else {
> +diff --git
> a/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java
> b/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java
> +index 513df4e..5f6e2f2 100644
> +--- a/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java
> b/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java
> +@@ -25,10 +25,11 @@ import java.util.Map;
> + import java.util.Set;
> +
> + import org.apache.solr.common.IteratorWriter;
> ++import org.apache.solr.common.MapWriter;
> + import org.apache.solr.common.MapWriter.EntryWriter;
> + import org.apache.solr.common.PushWriter;
> + import org.apache.solr.common.SolrDocument;
> +-import org.apache.solr.common.MapWriter;
> ++import org.apache.solr.common.SolrDocumentList;
> + import org.apache.solr.common.params.SolrParams;
> + import org.apache.solr.common.util.NamedList;
> + import org.apache.solr.common.util.SimpleOrderedMap;
> +@@ -367,7 +368,8 @@ class JSONWriter extends TextResponseWriter {
> +
> + // SolrDocument will now have multiValued fields represented as a
> Collection,
> + // even if only a single value is returned for this document.
> +- if (val instanceof List) {
> ++ // For SolrDocumentList, use writeVal instead of writeArray
> ++ if (!(val instanceof SolrDocumentList) && val instanceof List) {
> + // shortcut this common case instead of going through writeVal again
> + writeArray(name,((Iterable)val).iterator());
> + } else {
> +diff --git a/solr/core/src/test/org/apache/solr/response/JSONWriterTest.java
> b/solr/core/src/test/org/apache/solr/response/JSONWriterTest.java
> +index 1b53150..68cebd2 100644
> +--- a/solr/core/src/test/org/apache/solr/response/JSONWriterTest.java
> b/solr/core/src/test/org/apache/solr/response/JSONWriterTest.java
> +@@ -22,7 +22,10 @@ import java.lang.reflect.Method;
> + import java.lang.reflect.Modifier;
> + import java.nio.charset.StandardCharsets;
> + import java.util.ArrayList;
> ++import java.util.Arrays;
> + import java.util.List;
> ++
> ++import org.apache.solr.JSONTestUtil;
> + import org.apache.solr.SolrTestCaseJ4;
> + import org.apache.solr.common.SolrDocument;
> + import org.apache.solr.common.SolrDocumentList;
> +@@ -130,9 +133,9 @@ public class
[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=16430413#comment-16430413
]
Karl Wright commented on LUCENE-8245:
-
[~ivera], I'm afraid that I don't think your solution is the right one.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-12202) solr-exporter.cmd cannot be run on Windows
[ https://issues.apache.org/jira/browse/SOLR-12202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Minoru Osuka updated SOLR-12202: Priority: Major (was: Critical) > solr-exporter.cmd cannot be run on Windows > -- > > Key: SOLR-12202 > URL: https://issues.apache.org/jira/browse/SOLR-12202 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3 >Reporter: Minoru Osuka >Priority: Major > > solr-exporter.cmd could not be run on Windows due to following: > - incorrect main class name. > - incorrect classpath specification. -- 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-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=16430421#comment-16430421
]
Ignacio Vera commented on LUCENE-8245:
--
I don't think it either. I will add later today or tomorrow a random test that
it is extremely good to find all these cases. It can be used to validate
solutions.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-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=16430427#comment-16430427
]
Karl Wright commented on LUCENE-8245:
-
Ok, looking at the crossings we get, here's the complete output:
{code}
[junit4] 1>
[junit4] 1> Considering edge [lat=-1.4506713533447755,
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182,
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
[junit4] 1> start point travel dist=-0.11274773940907501; end point
travel dist=3.268072236836579E-13
[junit4] 1> start point travel above dist=-0.11274773940806501; end point
travel above dist=1.336807223683658E-12
[junit4] 1> start point travel below dist=-0.11274773941008501; end point
travel below dist=-6.831927763163422E-13
[junit4] 1> start point testpoint dist=-0.34019438500826027; end point
testpoint dist=0.6525992822450555
[junit4] 1> start point testpoint above dist=-0.3401943850072502; end
point testpoint above dist=0.6525992822460656
[junit4] 1> start point testpoint below dist=-0.34019438500927035; end
point testpoint below dist=0.6525992822440454
[junit4] 1> Travel inner point [X=1.0, Y=-1.336807223683658E-12,
Z=-1.1771178322187736E-11]; edgeplane=0.0; travelInsidePlane=0.0
[junit4] 1> Test point inner point [X=0.7540698997149413,
Y=-0.07411317803504912, Z=-0.6525992822440454]; edgeplane=0.0;
testPointInsidePlane=0.0
[junit4] 1> Edge added 2 to innerCrossingCount
[junit4] 1> Test point outer point [X=0.7540698997131706,
Y=-0.07411317803527853, Z=-0.6525992822460656]; edgeplane=0.0;
testPointOutsidePlane=0.0
[junit4] 1> Edge added 1 to outerCrossingCount
[junit4] 1>
[junit4] 1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0,
Z=4.9E-324])] -> [lat=0.13953211802880663,
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361,
Z=0.139079795174987])]
[junit4] 1> start point travel dist=3.268072236836579E-13; end point
travel dist=-0.6365576248358092
[junit4] 1> start point travel above dist=1.336807223683658E-12; end
point travel above dist=-0.6365576248347993
[junit4] 1> start point travel below dist=-6.831927763163422E-13; end
point travel below dist=-0.6365576248368193
[junit4] 1> start point testpoint dist=0.6525992822450555; end point
testpoint dist=0.7916790774200425
[junit4] 1> start point testpoint above dist=0.6525992822460656; end
point testpoint above dist=0.7916790774210526
[junit4] 1> start point testpoint below dist=0.6525992822440454; end
point testpoint below dist=0.7916790774190324
[junit4] 1> Travel inner point [X=1.0, Y=-1.3368072236836578E-12,
Z=2.920754816285907E-13]; edgeplane=-5.0487097934144756E-29;
travelInsidePlane=2.0194839173657902E-28
[junit4] 1> Edge added 1 to innerCrossingCount
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]; edgeplane=2.5243548967072378E-29;
travelOutsidePlane=-1.0097419586828951E-28
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
The travel outer point it incorrectly finds has a distance to each intersecting
plane that's on the order of 1e-28. That basically says it's a real
intersection given the inputs. So that second edge does intersect the outer
envelope EVEN THOUGH it doesn't look like it should, based on the endpoint.
The only other thing that can be going wrong is that the edge endpoint's bounds
are just sloppy enough to permit this intersection to be included in the
crossings list, while it really should be rejected. I'll need more diagnostics
to rule that in or out as the underlying cause, but I'm getting busy at work
now so that's not going to happen for a while.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> show
[jira] [Commented] (SOLR-12096) Inconsistent response format in subquery transform
[
https://issues.apache.org/jira/browse/SOLR-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430432#comment-16430432
]
ASF subversion and git services commented on SOLR-12096:
Commit f83a8da05e298395d4b65996d140da0a3343b2d9 in lucene-solr's branch
refs/heads/master from [~ishan1604]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f83a8da ]
SOLR-12096: Removing redundant patch file
> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch,
> SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.testsubquery.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared
> to single-shard
> h1. Single Shard collection
> Request
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10001677",
> "score": 0.5,
> "_children_": {
> "numFound": 9,
> "start": 0,
> "docs": [
> {
> "uniqueId": "100016771",
> "score": 0.5
> },
> {
> "uniqueId": "100016772",
> "score": 0.5
> },
> {
> "uniqueId": "100016773",
> "score": 0.5
> }
> ]
> }
> }
> ]
> }
> }
> {code}
> Here, *_children_* suquery response is as expected (Based on documentation)
> h1. Multi Shard collection(2)
> Request
> {code:java}
> localhost:8983/solr/k_test_2/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 11,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
>
[jira] [Commented] (SOLR-12096) Inconsistent response format in subquery transform
[
https://issues.apache.org/jira/browse/SOLR-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430433#comment-16430433
]
ASF subversion and git services commented on SOLR-12096:
Commit 2b27dd846a5ed78e79c57626b759352a58dc5332 in lucene-solr's branch
refs/heads/branch_7x from [~ishan1604]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2b27dd8 ]
SOLR-12096: Removing redundant patch file
> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch,
> SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.testsubquery.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared
> to single-shard
> h1. Single Shard collection
> Request
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10001677",
> "score": 0.5,
> "_children_": {
> "numFound": 9,
> "start": 0,
> "docs": [
> {
> "uniqueId": "100016771",
> "score": 0.5
> },
> {
> "uniqueId": "100016772",
> "score": 0.5
> },
> {
> "uniqueId": "100016773",
> "score": 0.5
> }
> ]
> }
> }
> ]
> }
> }
> {code}
> Here, *_children_* suquery response is as expected (Based on documentation)
> h1. Multi Shard collection(2)
> Request
> {code:java}
> localhost:8983/solr/k_test_2/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> Response
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 11,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json"
[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=16430471#comment-16430471
]
Karl Wright commented on LUCENE-8245:
-
Last bit of debugging until later:
{code}
[junit4] 1> Travel outer point [X=1.0, Y=6.831927763163421E-13,
Z=-1.4926898632243605E-13]; edgeplane=2.5243548967072378E-29;
travelOutsidePlane=-1.0097419586828951E-28;
edgestartplane=-6.993093735168714E-13; edgeendplane=-0.6515740933786793
[junit4] 1> Edge added 1 to outerCrossingCount
{code}
The bad crossing point it finds is (it appears) on the wrong side of the edge's
start cutoff plane, at a value of -6.993093735168714E-13, which is *almost*
big enough to get it kicked out, but not quite.
The interesting thing is that the precision of sidedness checks in general
(which is what this is, in fact) is MUCH higher than 1e-12. But if we
decreased MINIMUM_RESOLUTION globally, we would not fix the issue, because the
above/below planes get closer to the travel plane by exactly a proportional
amount. Maybe it would be possible, though, to have a tighter bound on
SidedPlane.isWithin() than we'd have elsewhere? Or maybe we could apply an
alternate, tighter filter in the case of the crossing points in
GeoComplexPolygon alone. I'll have to think this through.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-8242) Rename IndexSearcher.createNormalizedWeight()
[
https://issues.apache.org/jira/browse/LUCENE-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430517#comment-16430517
]
Adrien Grand commented on LUCENE-8242:
--
+1 Maybe say that {{boost}} should be {{1}} in the {{@deprecated}} javadocs and
add an entry to {{lucene/MIGRATE.txt}}?
> Rename IndexSearcher.createNormalizedWeight()
> -
>
> Key: LUCENE-8242
> URL: https://issues.apache.org/jira/browse/LUCENE-8242
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8242.patch
>
>
> We don't have Weight normalization since LUCENE-7368, so this method name is
> just plain wrong.
--
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-12202) solr-exporter.cmd cannot be run on Windows
[ https://issues.apache.org/jira/browse/SOLR-12202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Minoru Osuka updated SOLR-12202: Attachment: SOLR-12202.patch > solr-exporter.cmd cannot be run on Windows > -- > > Key: SOLR-12202 > URL: https://issues.apache.org/jira/browse/SOLR-12202 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.3 >Reporter: Minoru Osuka >Priority: Major > Attachments: SOLR-12202.patch > > > solr-exporter.cmd could not be run on Windows due to following: > - incorrect main class name. > - incorrect classpath specification. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 1679 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1679/ Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseParallelGC 2 tests failed. FAILED: org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test Error Message: mismatch: 'These guys develop stuff'!='These guys help customers' @ response/docs/[0]/depts/docs/[0]/text_t Stack Trace: java.lang.AssertionError: mismatch: 'These guys develop stuff'!='These guys help customers' @ response/docs/[0]/depts/docs/[0]/text_t at __randomizedtesting.SeedInfo.seed([BB76B7056B642F86:332288DFC598427E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test(TestSubQueryTransformerDistrib.java:166) 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.response.transform.TestSubQueryTransformerDistrib.test
[jira] [Created] (LUCENE-8246) Allow to customize the number of deletes a merge claims
Simon Willnauer created LUCENE-8246: --- Summary: Allow to customize the number of deletes a merge claims Key: LUCENE-8246 URL: https://issues.apache.org/jira/browse/LUCENE-8246 Project: Lucene - Core Issue Type: Improvement Affects Versions: 7.4, master (8.0) Reporter: Simon Willnauer Fix For: 7.4, master (8.0) With the introduction of soft deletes no every merge claims all documents that are marked as deleted in the segment readers. MergePolicies still need to do accurate accounting in order to select segments for merging and need to decide if segments are merged. This chance allows the merge policy to customize the number of deletes a merge of a segment claims. -- 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-8246) Allow to customize the number of deletes a merge claims
[ https://issues.apache.org/jira/browse/LUCENE-8246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-8246: Attachment: LUCENE-8246.patch > Allow to customize the number of deletes a merge claims > --- > > Key: LUCENE-8246 > URL: https://issues.apache.org/jira/browse/LUCENE-8246 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8246.patch > > > With the introduction of soft deletes no every merge claims all documents > that are marked as deleted in the segment readers. MergePolicies still need > to do accurate accounting in order to select segments for merging and need to > decide if segments are merged. This chance allows the merge policy to > customize the number of deletes a merge of a segment claims. -- 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-8246) Allow to customize the number of deletes a merge claims
[ https://issues.apache.org/jira/browse/LUCENE-8246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430552#comment-16430552 ] Simon Willnauer commented on LUCENE-8246: - https://github.com/s1monw/lucene-solr/pull/10 FYI [~mikemccand] > Allow to customize the number of deletes a merge claims > --- > > Key: LUCENE-8246 > URL: https://issues.apache.org/jira/browse/LUCENE-8246 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8246.patch > > > With the introduction of soft deletes no every merge claims all documents > that are marked as deleted in the segment readers. MergePolicies still need > to do accurate accounting in order to select segments for merging and need to > decide if segments are merged. This chance allows the merge policy to > customize the number of deletes a merge of a segment claims. -- 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-12198) Stream Evaluators should not copy matrices needlessly
[ https://issues.apache.org/jira/browse/SOLR-12198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-12198: -- Attachment: SOLR-12198.patch > Stream Evaluators should not copy matrices needlessly > - > > Key: SOLR-12198 > URL: https://issues.apache.org/jira/browse/SOLR-12198 > 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-12198.patch > > > Currently several of the Stream Evaluators that work with matrices are > creating multiple copies of the underlying multi-dimensional arrays. This can > lead to excessive memory usage. This ticket will change these implementations > so copies of the multi-dimensional arrays that back a matrix are only copied > when the *copyOf* function is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1526 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1526/ 2 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl Error Message: expected: but was:<.numFound:500!=496> Stack Trace: java.lang.AssertionError: expected: but was:<.numFound:500!=496> at __randomizedtesting.SeedInfo.seed([9AE936E4347BA6AE:8152C79B55C4DE18]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl(TestReplicationHandler.java:803) 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.doTestStressReplication Error Message: expected:<847> but was:<735> Stack Trace: java.lang.AssertionError: expected:<847
[jira] [Updated] (SOLR-12139) Support "eq" function for string fields
[
https://issues.apache.org/jira/browse/SOLR-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kudryavtsev updated SOLR-12139:
--
Attachment: SOLR-12139.patch
> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string
> types as well?
--
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-12139) Support "eq" function for string fields
[
https://issues.apache.org/jira/browse/SOLR-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430614#comment-16430614
]
Andrey Kudryavtsev commented on SOLR-12139:
---
Good work, David. I just added couple more tests for cases mentioned above
(varying types, i.e. string - numeric comparisons, null values)
> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string
> types as well?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2480 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2480/
2 tests failed.
FAILED: org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testRestoreState
Error Message:
Did not expect the processor to fire on first run! event={
"id":"13f45dd0dc99d3T2mp8mcx8wnw5re9d8a10cs8zd",
"source":"node_added_trigger", "eventTime":5616708330756563,
"eventType":"NODEADDED", "properties":{ "eventTimes":[
5616708330756563, 5616708330758428, 5616708330759165,
5616708330759848], "nodeNames":[ "127.0.0.1:38746_solr",
"127.0.0.1:37070_solr", "127.0.0.1:33003_solr",
"127.0.0.1:37817_solr"]}}
Stack Trace:
java.lang.AssertionError: Did not expect the processor to fire on first run!
event={
"id":"13f45dd0dc99d3T2mp8mcx8wnw5re9d8a10cs8zd",
"source":"node_added_trigger",
"eventTime":5616708330756563,
"eventType":"NODEADDED",
"properties":{
"eventTimes":[
5616708330756563,
5616708330758428,
5616708330759165,
5616708330759848],
"nodeNames":[
"127.0.0.1:38746_solr",
"127.0.0.1:37070_solr",
"127.0.0.1:33003_solr",
"127.0.0.1:37817_solr"]}}
at
__randomizedtesting.SeedInfo.seed([FBB595EFC01A88B8:351B317C3823F0AE]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.lambda$new$0(NodeAddedTriggerTest.java:49)
at
org.apache.solr.cloud.autoscaling.NodeAddedTrigger.run(NodeAddedTrigger.java:161)
at
org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testRestoreState(NodeAddedTriggerTest.java:257)
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(StatementA
Re: TestPerFieldDocValuesFormat timeout
Dawid: It's certainly possible. I'm working on LUCENE-7976 and one of my attempts did exactly that. There's a tricky bit of code there where a forceMerge merges some segments and then gets called again for them to get merged in turn (this to respect maxMergeAtOnceExplicit which defaults to 30). If the logic was a bit off it could keep going. I think another place I messed up was when the merging didn't have maxMergeAtOnce segments. one of the find*Merges kept being called because there were segments to merge but never merged any because of a faulty conditional. I took a quick look at the test output and don't see _what_ merge policy is being used though. I _don't_ think TMP has this problem, but don't know about any of the other merge policies. In the FWIW category, TMP.findMerges() gets a MergeTrigger as a parameter but then totally ignores it (even in the current code). Erick On Mon, Apr 9, 2018 at 1:06 AM, Dawid Weiss wrote: > There is an odd timeout failure here: > https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/195/consoleFull > > The TestPerFieldDocValuesFormat timed out. The stack trace shows just > one relevant thread in the enforced index merge, never returning from > the loop awaiting the number of segments to reach the desired number. > Is it possible that the merge policy ignores MergeTrigger.EXPLICIT > this this results in an endless loop? > >[junit4] 2>4) Thread[id=12, > name=TEST-TestPerFieldDocValuesFormat.testSparseBinaryFixedLengthVsStoredFields-seed#[617399315453E295], > state=TIMED_WAITING, group=TGRP-TestPerFieldDocValuesFormat] >[junit4] 2> at java.lang.Object.wait(Native Method) >[junit4] 2> at > org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4716) >[junit4] 2> at > org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2191) >[junit4] 2> at > org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2119) >[junit4] 2> at > org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:445) >[junit4] 2> at > org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestBinaryVsStoredFields(BaseDocValuesFormatTestCase.java:1472) >[junit4] 2> at > org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestBinaryFixedLengthVsStoredFields(BaseDocValuesFormatTestCase.java:1508) >[junit4] 2> at > org.apache.lucene.index.BaseDocValuesFormatTestCase.testSparseBinaryFixedLengthVsStoredFields(BaseDocValuesFormatTestCase.java:1501) > > Dawid > > - > 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] (SOLR-9562) Minimize queried collections for time series alias
[
https://issues.apache.org/jira/browse/SOLR-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430652#comment-16430652
]
David Smiley commented on SOLR-9562:
Mosh, I suppose you meant that CloudSolrClient could determine the set of
collections to be searched at its side and then send them via
{{collection=}} That's possible... but if done at the Solr side then
clients other than Java could leverage this.
> Minimize queried collections for time series alias
> --
>
> Key: SOLR-9562
> URL: https://issues.apache.org/jira/browse/SOLR-9562
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Eungsop Yoo
>Priority: Minor
> Attachments: SOLR-9562-v2.patch, SOLR-9562.patch
>
>
> For indexing time series data(such as large log data), we can create a new
> collection regularly(hourly, daily, etc.) with a write alias and create a
> read alias for all of those collections. But all of the collections of the
> read alias are queried even if we search over very narrow time window. In
> this case, the docs to be queried may be stored in very small portion of
> collections. So we don't need to do that.
> I suggest this patch for read alias to minimize queried collections. Three
> parameters for CREATEALIAS action are added.
> || Key || Type || Required || Default || Description ||
> | timeField | string | No | | The time field name for time series data. It
> should be date type. |
> | dateTimeFormat | string | No | | The format of timestamp for collection
> creation. Every collection should has a suffix(start with "_") with this
> format.
> Ex. dateTimeFormat: MMdd, collectionName: col_20160927
> See
> [DateTimeFormatter|https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html].
> |
> | timeZone | string | No | | The time zone information for dateTimeFormat
> parameter.
> Ex. GMT+9.
> See
> [DateTimeFormatter|https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html].
> |
> And then when we query with filter query like this "timeField:\[fromTime TO
> toTime\]", only the collections have the docs for a given time range will be
> queried.
--
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-8242) Rename IndexSearcher.createNormalizedWeight()
[ https://issues.apache.org/jira/browse/LUCENE-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430666#comment-16430666 ] ASF subversion and git services commented on LUCENE-8242: - Commit 798d3510341fa08e766776433d4f403a28f2d314 in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=798d351 ] LUCENE-8242: Deprecate createNormalizedWeight > Rename IndexSearcher.createNormalizedWeight() > - > > Key: LUCENE-8242 > URL: https://issues.apache.org/jira/browse/LUCENE-8242 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8242.patch > > > We don't have Weight normalization since LUCENE-7368, so this method name is > just plain wrong. -- 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-8242) Rename IndexSearcher.createNormalizedWeight()
[ https://issues.apache.org/jira/browse/LUCENE-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430665#comment-16430665 ] ASF subversion and git services commented on LUCENE-8242: - Commit 211e0ec84ac2b2d3de0ba666da1d80c1242da1b8 in lucene-solr's branch refs/heads/branch_7x from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=211e0ec ] LUCENE-8242: Deprecate createNormalizedWeight > Rename IndexSearcher.createNormalizedWeight() > - > > Key: LUCENE-8242 > URL: https://issues.apache.org/jira/browse/LUCENE-8242 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8242.patch > > > We don't have Weight normalization since LUCENE-7368, so this method name is > just plain wrong. -- 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-8242) Rename IndexSearcher.createNormalizedWeight()
[ https://issues.apache.org/jira/browse/LUCENE-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430667#comment-16430667 ] ASF subversion and git services commented on LUCENE-8242: - Commit e30264b31400a147507aabd121b1152020b8aa6d in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e30264b ] LUCENE-8242: Remove IndexSearcher.createNormalizedWeight > Rename IndexSearcher.createNormalizedWeight() > - > > Key: LUCENE-8242 > URL: https://issues.apache.org/jira/browse/LUCENE-8242 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8242.patch > > > We don't have Weight normalization since LUCENE-7368, so this method name is > just plain wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8242) Rename IndexSearcher.createNormalizedWeight()
[ https://issues.apache.org/jira/browse/LUCENE-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-8242. --- Resolution: Fixed Fix Version/s: master (8.0) 7.4 Thanks for the reviews > Rename IndexSearcher.createNormalizedWeight() > - > > Key: LUCENE-8242 > URL: https://issues.apache.org/jira/browse/LUCENE-8242 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8242.patch > > > We don't have Weight normalization since LUCENE-7368, so this method name is > just plain wrong. -- 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-12203) Error in response for field containing date. Unexpected state.
Jeroen Steggink created SOLR-12203:
--
Summary: Error in response for field containing date. Unexpected
state.
Key: SOLR-12203
URL: https://issues.apache.org/jira/browse/SOLR-12203
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Schema and Analysis
Affects Versions: 7.2.1, 7.3
Reporter: Jeroen Steggink
I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field:
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
at
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
at
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
at
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748){noformat}
I can't find out why this occurs. The weird thing is, I can't seem to find this
field (ds_lastModified) in the schema. I tried looking it up using Luke, but
also no result (/solr/some-core/admin/luke?fl=ds_lastModified). I do know that
at some point there were documents with this field. Seems like a bug. Any idea?
--
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-12203) Error in response for field containing date. Unexpected state.
[
https://issues.apache.org/jira/browse/SOLR-12203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen Steggink updated SOLR-12203:
---
Description:
I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field:
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
at
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
at
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
at
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748){noformat}
I can't find out why this occurs. The weird thing is, I can't seem to find this
field (ds_lastModified) in the schema. I tried looking it up using Luke, but
also no result (/solr/some-core/admin/luke?fl=ds_lastModified). I do know that
at some point there were documents with this field. Seems like a bug. Any idea?
Not sure if it's related, but checking another DatePointField using Luke, I get
the following error:
{noformat}
"java.lang.ArrayIndexOutOfBoundsException: 6\n\tat
org.apache.lucene.util.NumericUtils.sortableBytesToLong(NumericUtils.java:183)\n\tat
org.apache.lucene.document.LongPoint.decodeDimension(LongPoint.java:139)\n\tat
org.apache.solr.schema.DatePointField.indexedToReadable(DatePointField.java:179)\n\tat
org.apache.solr.schema.PointField.indexedToReadable(PointField.java:218)\n\tat
org.apache.solr.handler.admin.LukeRequestHandler$TopTermQueue.toNamedList(LukeRequestHandler.java:792)\n\tat
org.apache.solr.handler.admin.LukeRequestHandler.getDetailedFieldInfo(LukeRequestHandler.java:688)\n\tat
org.apache.solr.han
[jira] [Commented] (SOLR-10783) Using Hadoop Credential Provider as SSL/TLS store password source
[ https://issues.apache.org/jira/browse/SOLR-10783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430727#comment-16430727 ] Mark Miller commented on SOLR-10783: Thanks Mano. I'll look at this again today. > Using Hadoop Credential Provider as SSL/TLS store password source > - > > Key: SOLR-10783 > URL: https://issues.apache.org/jira/browse/SOLR-10783 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Affects Versions: 7.0 >Reporter: Mano Kovacs >Assignee: Mark Miller >Priority: Major > Attachments: SOLR-10783-fix.patch, SOLR-10783.patch, > SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch, > SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch > > > As a second iteration of SOLR-10307, I propose support of hadoop credential > providers as source of SSL store passwords. > Motivation: When SOLR is used in hadoop environment, support of HCP gives > better integration and unified method to pass sensitive credentials to SOLR. -- 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: [JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 196 - Failure
this is an endless merge loop due to merge policy accounting issues that were not implemented yet. I opened https://issues.apache.org/jira/browse/LUCENE-8246 On Mon, Apr 9, 2018 at 12:19 PM, Simon Willnauer wrote: > I am looking into this > > On Mon, Apr 9, 2018 at 12:06 PM, Apache Jenkins Server > wrote: >> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/196/ >> >> 5 tests failed. >> FAILED: >> org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention >> >> Error Message: >> GC overhead limit exceeded >> >> Stack Trace: >> java.lang.OutOfMemoryError: GC overhead limit exceeded >> at >> __randomizedtesting.SeedInfo.seed([248C95A59BE17434:3432A38A78701E91]:0) >> at java.util.HashMap$KeySet.iterator(HashMap.java:917) >> at java.util.HashSet.iterator(HashSet.java:173) >> at >> org.apache.lucene.index.IndexWriter.maxNumSegmentsMergesPending(IndexWriter.java:2216) >> at >> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2190) >> at >> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2119) >> at >> org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention(TestSoftDeletesRetentionMergePolicy.java:266) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) >> at >> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) >> at >> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) >> at >> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) >> at >> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) >> at >> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) >> at >> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >> at >> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) >> at >> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) >> at >> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) >> at >> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) >> at >> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >> at >> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) >> at >> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) >> at >> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) >> >> >> FAILED: >> junit.framework.TestSuite.org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy >> >> Error Message: >> 2 threads leaked from SUITE scope at >> org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy: 1) >> Thread[id=289762, name=Lucene Merge Thread #281215, state=RUNNABLE, >> group=TGRP-TestSoftDeletesRetentionMergePolicy] at >> java.lang.Thread.yield(Native Method) at >> org.apache.lucene.store.MockDirectoryWrapper.maybeYield(MockDirectoryWrapper.java:626) >> at >> org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:644) >> at >> org.apache.lucene.store.LockValidatingDirectoryWrapper.createOutput(LockValidatingDirectoryWrapper.java:44) >> at >> org.apache.lucene.index.ConcurrentMergeScheduler$1.createOutput(ConcurrentMergeSched
[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=16430770#comment-16430770
]
Boris Pasko commented on SOLR-6305:
---
[~elyograg] you're absolutely right. For solr, HDFS is just another block
storage. It does not use any HDFS-specific replication strategies, for example,
copying files as Map/Reduce job. Therefore, having 3 solr replicas and default
replication factor of 3 actually produces 3 data copies.
The storage space itself is typically less of the concern, the bigger concern
is network traffic. Bytes that has to be moved to 3 datanodes instead of 1
datanode.
> 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-12139) Support "eq" function for string fields
[
https://issues.apache.org/jira/browse/SOLR-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430795#comment-16430795
]
ASF subversion and git services commented on SOLR-12139:
Commit f0aed933a6674dadf7a563973c6d46e99901c5e6 in lucene-solr's branch
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f0aed93 ]
SOLR-12139: eq() now works on strings and perhaps anything
> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string
> types as well?
--
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-12139) Support "eq" function for string fields
[
https://issues.apache.org/jira/browse/SOLR-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430797#comment-16430797
]
ASF subversion and git services commented on SOLR-12139:
Commit 385449e61731c128700ef9bb532cc182aac01d47 in lucene-solr's branch
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=385449e ]
SOLR-12139: eq() now works on strings and perhaps anything
(cherry picked from commit f0aed93)
> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string
> types as well?
--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031
Hrishikesh Gadre created SOLR-12204: --- Summary: Upgrade commons-fileupload to address CVE-2016-131 Key: SOLR-12204 URL: https://issues.apache.org/jira/browse/SOLR-12204 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.2 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Currently SOLR is using 1.3.2 version of commons-fileupload library which is susceptible to CVE-2016-131. We should upgrade the this library to the latest version (1.3.3 at the time of writing) to mitigate the security risk. -- 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
Potential BadApple report this week
OK, this is the first week I have Hoss' report from two weeks ago so the list is rather lengthy. I believe this test is being actively worked on, so no BadApple for it org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue ***Tests I'll BadApple on Thursday. These are tests that failed in the last week and _also_ are failures in Hoss' report from two weeks ago, so nobody has addressed them in that time-frame. PLEASE LET ME KNOW BEFORE THURSDAY WHICH OF THESE SHOULD NOT BE BADAPPLEd org.apache.lucene.index.TestIndexSorting.testRandom3 org.apache.solr.TestDistributedSearch.test org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions org.apache.solr.cloud.AddReplicaTest.test org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1 org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate org.apache.solr.cloud.CreateRoutedAliasTest.testV1 org.apache.solr.cloud.CreateRoutedAliasTest.testV2 org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState org.apache.solr.common.cloud.TestCollectionStateWatchers.testDeletionsTriggerWatches org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.test ***Tests currently BadApple-d *AwaitsFix Annotations: Lucene AwaitsFix TestControlledRealTimeReopenThread.java testCRTReopen() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5737";) TestICUNormalizer2CharFilter.java testRandomStrings() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5595";) TestMoreLikeThis.java testMultiFieldShouldReturnPerFieldBooleanQuery() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-7161";) UIMABaseAnalyzerTest.java testRandomStrings() @Test @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-3869";) UIMABaseAnalyzerTest.java testRandomStringsWithConfigurationParameters() @Test @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-3869";) UIMATypeAwareAnalyzerTest.java testRandomStrings() @Test @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-3869";) Solr AwaitsFix ReplaceNodeNoTargetTest.java ReplaceNodeNoTargetTest suite @LuceneTestCase.AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/SOLR-11067";) TestCollapseQParserPlugin.java testStringCollapse() @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-11974";) TestImpersonationWithHadoopAuth.java testForwarding() @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/HADOOP-9893";) TestLTRReRankingPipeline.java testDifferentTopN() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/SOLR-11134";) TestMinMaxOnMultiValuedField.java testDoubleFieldCache() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";) TestMinMaxOnMultiValuedField.java testFloatFieldCache() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";) TestMinMaxOnMultiValuedField.java testIntFieldCache() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";) TestMinMaxOnMultiValuedField.java testLongFieldCache() @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";) *BadApple Annotations: Lucene BadApple TestLRUQueryCache.java testDocValuesUpdatesDontBreakCache() @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";) Solr BadApple AliasIntegrationTest.java testModifyPropertiesCAR() @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";) AliasIntegrationTest.java testProperties() @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";) AutoAddReplicasIntegrationTest.java
BadApple 2
Here are the failures in the last week by (rough) category: *No ZK node NoNode junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.JDBCStreamTest *Timeout (or time related)/session expired/thread leak/zombie threads/Object tracker junit.framework.TestSuite.org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat junit.framework.TestSuite.org.apache.lucene.codecs.perfield.TestPerFieldDocValuesFormat junit.framework.TestSuite.org.apache.lucene.index.TestIndexSorting junit.framework.TestSuite.org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyFieldFacetExtrasCloudTest junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamDecoratorTest junit.framework.TestSuite.org.apache.solr.cloud.cdcr.CdcrBootstrapTest junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest junit.framework.TestSuite.org.apache.solr.cloud.TestLeaderElectionZkExpiry junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest SOLR-12200 ZkControllerTest failure. Leaking Overseer junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler junit.framework.TestSuite.org.apache.solr.response.transform.TestSubQueryTransformerDistrib junit.framework.TestSuite.org.apache.solr.uninverting.TestDocTermOrds junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat.testGCDCompression org.apache.lucene.codecs.perfield.TestPerFieldDocValuesFormat.testSparseBinaryFixedLengthVsStoredFields org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test org.apache.solr.handler.TestReplicationHandler.doTestStressReplication ***OutOfMemory/GC overhead exceeded. DON'T BADAPPLE THESE? org.apache.lucene.index.TestIndexWriterOnVMError.testOOM org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention org.apache.lucene.search.TestCustomSearcherSort.testFieldSortCustomSearcher org.apache.lucene.search.TestCustomSearcherSort.testFieldSortSingleSearcher org.apache.solr.uninverting.TestDocTermOrds.testActuallySingleValued org.apache.solr.uninverting.TestDocTermOrds.testBackToTheFuture org.apache.solr.uninverting.TestDocTermOrds.testRandom org.apache.solr.uninverting.TestDocTermOrds.testRandomWithPrefix org.apache.solr.uninverting.TestDocTermOrds.testSimple org.apache.solr.uninverting.TestDocTermOrds.testSortedTermsEnum org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit SOLR-12147 TestDocTermOrds.testTriggerUnInvertLimit should not use MemoryCodec **No Live Servers/Could not find collection org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete **Error starting mini SolrCloud cluster **I/O Exception **Mock Directory (open files) *Other (typically asserts.) junit.framework.TestSuite.org.apache.lucene.search.TestCustomSearcherSort junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyFieldFacetExtrasCloudTest junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamingTest junit.framework.TestSuite.org.apache.solr.common.cloud.TestCollectionStateWatchers junit.framework.TestSuite.org.apache.solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin org.apache.lucene.index.TestIndexSorting.testRandom3 org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelExecutorStream org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testGammaDistribution org.apache.solr.cloud.AddReplicaTest.test org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1 org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testRestoreState org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate org.apache.solr.cloud.CreateRoutedAliasTest.testV1 org.apache.solr.cloud.CreateRoutedAliasTest.testV2 org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing org.apache.solr.cloud.DistribCursorPagingTest.test org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest.test org.apache.solr.cloud.hdfs.StressHdfsTest.test org.apach
Re: Potential BadApple report this week
Hi Erick, Please don’t BadApple any TestReplicationHandler tests, I’m looking at them this week: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Thanks, -- Steve www.lucidworks.com > On Apr 9, 2018, at 12:32 PM, Erick Erickson wrote: > > OK, this is the first week I have Hoss' report from two weeks ago so > the list is rather lengthy. > > > I believe this test is being actively worked on, so no BadApple for it > org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue > > ***Tests I'll BadApple on Thursday. > > These are tests that failed in the last week and _also_ are failures > in Hoss' report from two weeks ago, so nobody has addressed them in > that time-frame. > > PLEASE LET ME KNOW BEFORE THURSDAY WHICH OF THESE SHOULD NOT BE BADAPPLEd > > org.apache.lucene.index.TestIndexSorting.testRandom3 > org.apache.solr.TestDistributedSearch.test > > org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions > org.apache.solr.cloud.AddReplicaTest.test > org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1 > org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test > org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent > org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate > org.apache.solr.cloud.CreateRoutedAliasTest.testV1 > org.apache.solr.cloud.CreateRoutedAliasTest.testV2 > org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing > org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest > org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState > org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest > > org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete > > org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections > org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger > > org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState > > org.apache.solr.common.cloud.TestCollectionStateWatchers.testDeletionsTriggerWatches > > org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication > org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl > > org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload > org.apache.solr.handler.TestReplicationHandler.doTestStressReplication > org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory > org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.test > > > ***Tests currently BadApple-d > > *AwaitsFix Annotations: > > > Lucene AwaitsFix > TestControlledRealTimeReopenThread.java > testCRTReopen() > @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5737";) > > TestICUNormalizer2CharFilter.java > testRandomStrings() > @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5595";) > > TestMoreLikeThis.java > testMultiFieldShouldReturnPerFieldBooleanQuery() > @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-7161";) > > UIMABaseAnalyzerTest.java > testRandomStrings() > @Test @AwaitsFix(bugUrl = > "https://issues.apache.org/jira/browse/LUCENE-3869";) > > UIMABaseAnalyzerTest.java > testRandomStringsWithConfigurationParameters() > @Test @AwaitsFix(bugUrl = > "https://issues.apache.org/jira/browse/LUCENE-3869";) > > UIMATypeAwareAnalyzerTest.java > testRandomStrings() > @Test @AwaitsFix(bugUrl = > "https://issues.apache.org/jira/browse/LUCENE-3869";) > > >Solr AwaitsFix > ReplaceNodeNoTargetTest.java > ReplaceNodeNoTargetTest suite > @LuceneTestCase.AwaitsFix(bugUrl = > "https://issues.apache.org/jira/browse/SOLR-11067";) > > TestCollapseQParserPlugin.java > testStringCollapse() > @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-11974";) > > TestImpersonationWithHadoopAuth.java > testForwarding() > @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/HADOOP-9893";) > > TestLTRReRankingPipeline.java > testDifferentTopN() > @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/SOLR-11134";) > > TestMinMaxOnMultiValuedField.java > testDoubleFieldCache() > @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";) > > TestMinMaxOnMultiValuedField.java > testFloatFieldCache() > @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";) > > TestMinMaxOnMultiValuedField.java > testIntFieldCache() > @AwaitsFix(bugUrl = "https://issues.apache.org/jira/br
[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=16430855#comment-16430855
]
Karl Wright commented on LUCENE-8245:
-
For fun, I tried to set it up so that the edge cutoff planes had a smaller
MINIMUM_RESOLUTION they used than everything else. This unexpectedly broke
everything. So then I tried having a smaller MINIMUM_RESOLUTION just for the
start/end planes for edges. This allowed me to get the current failing test to
start passing, but the other tests committed on the weekend started failing
instead. In fact, I could find a value for this that's not much different than
MINIMUM_RESOLUTION that led to ALL the complex polygon tests failing. That's a
rather worrisome development.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-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=16430931#comment-16430931
]
Karl Wright commented on LUCENE-8245:
-
Reasoning this through, the spacing between the travel plane and the above or
below plane should be exactly 2.0 * MINIMUM_RESOLUTION. That will guarantee
that any point that falls between the two planes is detected in one or the
other (or, very rarely, both). When I set it up this way, the LUCENE8245 test
starts passing, but the testAboveBelowCrossingDifferentEdges example now fails.
So I will next analyze why that occurs, and see if the problem in that case is
more readily addressable.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
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-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=16430935#comment-16430935
]
Ignacio Vera commented on LUCENE-8245:
--
I can give you an answer why it fails: In that case the planes above and below
cross different edges. Because we only consider edges that crosses the main
plain we miss one cross.
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-11-ea+5) - Build # 7260 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7260/ Java: 64bit/jdk-11-ea+5 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly Error Message: Unexpected number of elements in the group for intGSF: 6 Stack Trace: java.lang.AssertionError: Unexpected number of elements in the group for intGSF: 6 at __randomizedtesting.SeedInfo.seed([B4AF423516FBAB72:2F142C6D5BA3992C]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:379) 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.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue Error Message: action wasn't interrupted Stack Trace: java.lang.AssertionError: action wasn't interrupted at __randomizedtesting.SeedInfo.seed([B4AF423516FBAB72:7D1A009B1F9C6D87]:0) at org.junit
Re: Potential BadApple report this week
Cool. I'll put them on my permanent "don't BadApple" list. If they're still there in a month I'll ask again And for everyone. I have no objection at all to leaving failing tests in if people are working on them. I realize that sometimes the only way to get them to fail is to leave them running Erick On Mon, Apr 9, 2018 at 9:38 AM, Steve Rowe wrote: > Hi Erick, > > Please don’t BadApple any TestReplicationHandler tests, I’m looking at them > this week: > > > org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication > org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl > > org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload > org.apache.solr.handler.TestReplicationHandler.doTestStressReplication > > Thanks, > > -- > Steve > www.lucidworks.com > >> On Apr 9, 2018, at 12:32 PM, Erick Erickson wrote: >> >> OK, this is the first week I have Hoss' report from two weeks ago so >> the list is rather lengthy. >> >> >> I believe this test is being actively worked on, so no BadApple for it >> org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue >> >> ***Tests I'll BadApple on Thursday. >> >> These are tests that failed in the last week and _also_ are failures >> in Hoss' report from two weeks ago, so nobody has addressed them in >> that time-frame. >> >> PLEASE LET ME KNOW BEFORE THURSDAY WHICH OF THESE SHOULD NOT BE BADAPPLEd >> >> org.apache.lucene.index.TestIndexSorting.testRandom3 >> org.apache.solr.TestDistributedSearch.test >> >> org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions >> org.apache.solr.cloud.AddReplicaTest.test >> org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1 >> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test >> org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent >> org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate >> org.apache.solr.cloud.CreateRoutedAliasTest.testV1 >> org.apache.solr.cloud.CreateRoutedAliasTest.testV2 >> org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing >> org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest >> >> org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState >> org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest >> >> org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete >> >> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections >> org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger >> >> org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState >> >> org.apache.solr.common.cloud.TestCollectionStateWatchers.testDeletionsTriggerWatches >> >> org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication >> >> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl >> >> org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload >> org.apache.solr.handler.TestReplicationHandler.doTestStressReplication >> org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory >> org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.test >> >> >> ***Tests currently BadApple-d >> >> *AwaitsFix Annotations: >> >> >> Lucene AwaitsFix >> TestControlledRealTimeReopenThread.java >> testCRTReopen() >> @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5737";) >> >> TestICUNormalizer2CharFilter.java >> testRandomStrings() >> @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5595";) >> >> TestMoreLikeThis.java >> testMultiFieldShouldReturnPerFieldBooleanQuery() >> @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-7161";) >> >> UIMABaseAnalyzerTest.java >> testRandomStrings() >> @Test @AwaitsFix(bugUrl = >> "https://issues.apache.org/jira/browse/LUCENE-3869";) >> >> UIMABaseAnalyzerTest.java >> testRandomStringsWithConfigurationParameters() >> @Test @AwaitsFix(bugUrl = >> "https://issues.apache.org/jira/browse/LUCENE-3869";) >> >> UIMATypeAwareAnalyzerTest.java >> testRandomStrings() >> @Test @AwaitsFix(bugUrl = >> "https://issues.apache.org/jira/browse/LUCENE-3869";) >> >> >>Solr AwaitsFix >> ReplaceNodeNoTargetTest.java >> ReplaceNodeNoTargetTest suite >> @LuceneTestCase.AwaitsFix(bugUrl = >> "https://issues.apache.org/jira/browse/SOLR-11067";) >> >> TestCollapseQParserPlugin.java >> testStringCollapse() >> @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-11974";) >> >> TestImpersonationWithHadoopAuth.java >> testForwarding() >> @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/HADOOP-9893";) >> >> TestLTRReRankingPipeline.java >> testDifferentTopN()
[jira] [Commented] (SOLR-11971) CVE-2018-1308: XXE attack through DIH's dataConfig request parameter
[
https://issues.apache.org/jira/browse/SOLR-11971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430990#comment-16430990
]
Walter Underwood commented on SOLR-11971:
-
Is there a workaround for this that does not require upgrading?
> CVE-2018-1308: XXE attack through DIH's dataConfig request parameter
>
>
> Key: SOLR-11971
> URL: https://issues.apache.org/jira/browse/SOLR-11971
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 6.6.3, 7.3, master (8.0)
>
> Attachments: ApacheSolrDIH-XXE.pdf, SOLR-11971.patch
>
>
> We got a security report about an XXE attack when using the
> {{&dataConfig=}} of Solr's DataImportHandler. See the attached PDF
> file with full details (I converted it to PDF, originally it was a DOC file).
--
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
BeastIt! Report for Apache Solr Master
BeastIt Unit Test Beasting Summary Report for Apache Solr Master BeastIt gives unit tests a chance to duke it out in a fair but difficult environment. Each test is beasted and then judged. See a link to the full reports below. Number of Tests: Number Passed: 1077 % Passed: 96.94% Ran 30 iterations, 5 at a time Markers (Marked tests have one of these markers) @AwaitsFix: 1 @BadApple: 12 @Ignore: 3 *** Worst Test - Not Marked (It's your Moby Dick!) - TestTriggerIntegration 66% half–cracked '' If you catch that whale, next try - TestSubQueryTransformerDistrib 30% unreliable '' *** New Test(s) Failing?! Sound the alarm, we may have a cowboy here. - NodeAddedTriggerIntegrationTest 3% flakey *** New Failures in Test(s)?! Everything looked so good! - HdfsBasicDistributedZkTest 3% flakey was 0,0,0,0 - ForceLeaderTest 3% flakey was 0,0,0,0 - TestRandomRequestDistribution 3% flakey was 0,0,0,0 - TestSubQueryTransformerDistrib 30% unreliable was 0,0,0,0 - TestV2Request 3% flakey was 0,0,0,0 - TestLeaderInitiatedRecoveryThread 3% flakey was 0,0,0,0 - NodeAddedTriggerIntegrationTest 3% flakey was 0 - NodeAddedTriggerTest 30% unreliable was 0,0,0,0 *** Slowest Test - CdcrReplicationDistributedZkTest 1752.99 unreliable '@BadApple @Nightly ' Can you speed me up? *** Worst Test - Marked (How long must it suffer the mark?) - CdcrReplicationDistributedZkTest 23% unreliable '@BadApple @Nightly ' *** Non Running Tests - Coverage Holes?! - ChaosMonkeyShardSplitTest '@Ignore ' - TestRankQueryPlugin '@Ignore ' - TestMailEntityProcessor '@Ignore ' Full Reports http://apache-solr.bitballoon.com (Report maintained by Mark Miller)
[JENKINS] Lucene-Solr-Tests-7.x - Build # 555 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/555/ 4 tests failed. FAILED: org.apache.solr.cloud.CreateRoutedAliasTest.testV1 Error Message: Error from server at http://127.0.0.1:43553/solr: Collection : testV2_2018-04-09 is part of alias testV2 remove or modify the alias before removing this collection. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:43553/solr: Collection : testV2_2018-04-09 is part of alias testV2 remove or modify the alias before removing this collection. at __randomizedtesting.SeedInfo.seed([85419656E30CFDC1:2A8F5126A2E15151]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) 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.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:451) at org.apache.solr.cloud.CreateRoutedAliasTest.doBefore(CreateRoutedAliasTest.java:96) 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$9.evaluate(RandomizedRunner.java:968) 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
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.4) - Build # 537 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/537/ Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC 9 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: --> http://127.0.0.1:50090/collection1_shard2_replica_n41:Failed to execute sqlQuery 'select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc' against JDBC connection 'jdbc:calcitesolr:'. Error while executing SQL "select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc": java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:50162/collection1_shard2_replica_n45/:can not sort on a field w/o docValues unless it is indexed and supports Uninversion: field_i Stack Trace: java.io.IOException: --> http://127.0.0.1:50090/collection1_shard2_replica_n41:Failed to execute sqlQuery 'select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc' against JDBC connection 'jdbc:calcitesolr:'. Error while executing SQL "select id, field_i, str_s from collection1 where (text='()' OR text='') AND text='' order by field_i desc": java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:50162/collection1_shard2_replica_n45/:can not sort on a field w/o docValues unless it is indexed and supports Uninversion: field_i at __randomizedtesting.SeedInfo.seed([C179A84DEEA46BDE:663D10E9831F7867]:0) at org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:222) at org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2522) at org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:124) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:82) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) 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:
[jira] [Commented] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
[
https://issues.apache.org/jira/browse/SOLR-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431123#comment-16431123
]
Jason Gerlowski commented on SOLR-10453:
When I created this a while back, it was in a group of related stories centered
around making our {{SolrClient}} implementations more immutable (and hopefully
safer for multi-threading). In generating those JIRAs, I grabbed a list of all
the "setters" I saw, and must have missed that this one was
internal/not-a-setter.
So to answer your actual question, I don't think this is a duplicate of
SOLR-12194, but you were right to close it (if only because it's invalid).
> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each
> {{SolrClient}} can be deprecated, and their functionality moved over to the
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy"
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}}
> setter on all {{SolrClient}} 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] [Reopened] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
[
https://issues.apache.org/jira/browse/SOLR-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reopened SOLR-10453:
> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each
> {{SolrClient}} can be deprecated, and their functionality moved over to the
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy"
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}}
> setter on all {{SolrClient}} 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] [Resolved] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
[
https://issues.apache.org/jira/browse/SOLR-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-10453.
Resolution: Invalid
Marking as invalid
> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each
> {{SolrClient}} can be deprecated, and their functionality moved over to the
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy"
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}}
> setter on all {{SolrClient}} 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] [Assigned] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
[
https://issues.apache.org/jira/browse/SOLR-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-10453:
--
Assignee: (was: Jan Høydahl)
> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each
> {{SolrClient}} can be deprecated, and their functionality moved over to the
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy"
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}}
> setter on all {{SolrClient}} 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] [Closed] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
[
https://issues.apache.org/jira/browse/SOLR-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl closed SOLR-10453.
--
> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each
> {{SolrClient}} can be deprecated, and their functionality moved over to the
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy"
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}}
> setter on all {{SolrClient}} 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] [Updated] (SOLR-12203) Error in response for field containing date. Unexpected state.
[
https://issues.apache.org/jira/browse/SOLR-12203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeroen Steggink updated SOLR-12203:
---
Description:
I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field:
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
at
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
at
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
at
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748){noformat}
I can't find out why this occurs. The weird thing is, I can't seem to find this
field (ds_lastModified) in the schema. I tried looking it up using Luke, but
also no result (/solr/some-core/admin/luke?fl=ds_lastModified). I do know that
at some point there were documents with this field. Seems like a bug. Any idea?
was:
I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field:
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at
org.apache.solr.response.JSONWriter.writeNamedLis
[jira] [Commented] (SOLR-11251) Ref Guide: Add docs on JSON facet module
[
https://issues.apache.org/jira/browse/SOLR-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431211#comment-16431211
]
Mikhail Khludnev commented on SOLR-11251:
-
I want to rephrase [the suggestion regarding
debugging|https://lucene.apache.org/solr/guide/7_1/json-request-api.html#debugging].
bq. If you want to see what your merged/parsed JSON looks like, you can turn on
debugging (debug=true), and it will come back under the "json" key along with
the other debugging information.
This suggestion doesn't work on large indices, {{debug=true}} as well as
{{debugQuery=true}} just never get back due to overall burden. The situation is
even tricker since {{debug=query}} isn't propagated to slaves in the
distributed search. The option I've found is {{debug=timing}}, which works like
a charm but lacks of cluelessness. Should we put as just as
bq. If you want to see what your merged/parsed JSON looks like, you can turn on
debugging (debug=timing), and it will come back under the "json" key along with
the other debugging information.
Or also mention such caveat/explanations as well (which might be good for SEO
reasons, btw).
bq. Note: that debug=true as well as debugQuery=true might have enormous impact
on request time, and debug=true is ignored for json.facet.
> Ref Guide: Add docs on JSON facet module
>
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON
> facets, but it never made its way into the published guides. During the
> conversion of the Ref Guide from Confluence, I made sure the page was
> exported and converted to {{.adoc}} format.
> The doc was never updated after any of the changes that have been made to
> JSON facet functionality since it was originally written, so it's possibly
> inaccurate or just out of date. Someone could take a crack at finishing the
> conversion cleanup and updating it with latest information so someday it can
> be part of the published Guide.
--
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-12205) SOLR-7887 broke javadoc:jar in maven
Daniel Collins created SOLR-12205:
-
Summary: SOLR-7887 broke javadoc:jar in maven
Key: SOLR-12205
URL: https://issues.apache.org/jira/browse/SOLR-12205
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Build
Affects Versions: 7.3, master (8.0)
Reporter: Daniel Collins
Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the
javadoc command line. That is not a javadoc option, so mvn javadoc:jar fails
both on master and branch_7x.
The following fix works for me:
{code:java}
diff --git a/dev-tools/maven/pom.xml.template b/dev-tools/maven/pom.xml.template
index 4e21ca0e13..50299a3cda 100644
--- a/dev-tools/maven/pom.xml.template
+++ b/dev-tools/maven/pom.xml.template
@@ -238,7 +238,6 @@
true
-Xdoclint:all
-Xdoclint:-missing
- -proc:none
{code}
The ant build is fine, its just the maven build which is affected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2481 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2481/ 1 tests failed. FAILED: org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test Error Message: mismatch: 'These guys help customers'!='These guys develop stuff' @ response/docs/[0]/depts/docs/[0]/text_t Stack Trace: java.lang.AssertionError: mismatch: 'These guys help customers'!='These guys develop stuff' @ response/docs/[0]/depts/docs/[0]/text_t at __randomizedtesting.SeedInfo.seed([2FD1598AA7C008EF:A7856650093C6517]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test(TestSubQueryTransformerDistrib.java:166) 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) Build Log: [...truncated 14426 lines...] [junit4] Suite: org.apache.solr.response.transform.TestSubQueryTran
[jira] [Assigned] (SOLR-12205) SOLR-7887 broke javadoc:jar in maven
[
https://issues.apache.org/jira/browse/SOLR-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe reassigned SOLR-12205:
-
Assignee: Steve Rowe
> SOLR-7887 broke javadoc:jar in maven
>
>
> Key: SOLR-12205
> URL: https://issues.apache.org/jira/browse/SOLR-12205
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 7.3, master (8.0)
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Major
> Labels: maven
>
> Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the
> javadoc command line. That is not a javadoc option, so mvn javadoc:jar fails
> both on master and branch_7x.
> The following fix works for me:
> {code:java}
> diff --git a/dev-tools/maven/pom.xml.template
> b/dev-tools/maven/pom.xml.template
> index 4e21ca0e13..50299a3cda 100644
> --- a/dev-tools/maven/pom.xml.template
> +++ b/dev-tools/maven/pom.xml.template
> @@ -238,7 +238,6 @@
> true
> -Xdoclint:all
> -Xdoclint:-missing
> - -proc:none
>
>
>
> {code}
> The ant build is fine, its just the maven build which is affected.
--
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-12205) SOLR-7887 broke javadoc:jar in maven
[
https://issues.apache.org/jira/browse/SOLR-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431380#comment-16431380
]
ASF subversion and git services commented on SOLR-12205:
Commit 7009f1cade6bd959d920aaaf819129b939e2f97a in lucene-solr's branch
refs/heads/branch_7x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7009f1c ]
SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized
annotation processing directive
> SOLR-7887 broke javadoc:jar in maven
>
>
> Key: SOLR-12205
> URL: https://issues.apache.org/jira/browse/SOLR-12205
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 7.3, master (8.0)
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Major
> Labels: maven
>
> Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the
> javadoc command line. That is not a javadoc option, so mvn javadoc:jar fails
> both on master and branch_7x.
> The following fix works for me:
> {code:java}
> diff --git a/dev-tools/maven/pom.xml.template
> b/dev-tools/maven/pom.xml.template
> index 4e21ca0e13..50299a3cda 100644
> --- a/dev-tools/maven/pom.xml.template
> +++ b/dev-tools/maven/pom.xml.template
> @@ -238,7 +238,6 @@
> true
> -Xdoclint:all
> -Xdoclint:-missing
> - -proc:none
>
>
>
> {code}
> The ant build is fine, its just the maven build which is affected.
--
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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431381#comment-16431381 ] ASF subversion and git services commented on SOLR-7887: --- Commit 7009f1cade6bd959d920aaaf819129b939e2f97a in lucene-solr's branch refs/heads/branch_7x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7009f1c ] SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized annotation processing directive > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887-fix-maven-compilation.patch, > SOLR-7887-followup_1.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
[ https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431383#comment-16431383 ] ASF subversion and git services commented on SOLR-7887: --- Commit a12d3988740eed3932d92ae28f60449c2c564f53 in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a12d398 ] SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized annotation processing directive > Upgrade Solr to use log4j2 -- log4j 1 now officially end of life > > > Key: SOLR-7887 > URL: https://issues.apache.org/jira/browse/SOLR-7887 > Project: Solr > Issue Type: Task >Reporter: Shawn Heisey >Assignee: Erick Erickson >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, > SOLR-7887-eoe-review.patch, SOLR-7887-fix-maven-compilation.patch, > SOLR-7887-followup_1.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, > SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch > > > The logging services project has officially announced the EOL of log4j 1: > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > In the official binary jetty deployment, we use use log4j 1.2 as our final > logging destination, so the admin UI has a log watcher that actually uses > log4j and java.util.logging classes. That will need to be extended to add > log4j2. I think that might be the largest pain point to this upgrade. > There is some crossover between log4j2 and slf4j. Figuring out exactly which > jars need to be in the lib/ext directory will take some research. -- 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-12205) SOLR-7887 broke javadoc:jar in maven
[
https://issues.apache.org/jira/browse/SOLR-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431382#comment-16431382
]
ASF subversion and git services commented on SOLR-12205:
Commit a12d3988740eed3932d92ae28f60449c2c564f53 in lucene-solr's branch
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a12d398 ]
SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized
annotation processing directive
> SOLR-7887 broke javadoc:jar in maven
>
>
> Key: SOLR-12205
> URL: https://issues.apache.org/jira/browse/SOLR-12205
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 7.3, master (8.0)
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Major
> Labels: maven
>
> Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the
> javadoc command line. That is not a javadoc option, so mvn javadoc:jar fails
> both on master and branch_7x.
> The following fix works for me:
> {code:java}
> diff --git a/dev-tools/maven/pom.xml.template
> b/dev-tools/maven/pom.xml.template
> index 4e21ca0e13..50299a3cda 100644
> --- a/dev-tools/maven/pom.xml.template
> +++ b/dev-tools/maven/pom.xml.template
> @@ -238,7 +238,6 @@
> true
> -Xdoclint:all
> -Xdoclint:-missing
> - -proc:none
>
>
>
> {code}
> The ant build is fine, its just the maven build which is affected.
--
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-12205) SOLR-7887 broke javadoc:jar in maven
[
https://issues.apache.org/jira/browse/SOLR-12205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-12205.
---
Resolution: Fixed
Fix Version/s: 7.4
Committed your patch, thanks [~dancollins]!
> SOLR-7887 broke javadoc:jar in maven
>
>
> Key: SOLR-12205
> URL: https://issues.apache.org/jira/browse/SOLR-12205
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
>Affects Versions: 7.3, master (8.0)
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Major
> Labels: maven
> Fix For: 7.4
>
>
> Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the
> javadoc command line. That is not a javadoc option, so mvn javadoc:jar fails
> both on master and branch_7x.
> The following fix works for me:
> {code:java}
> diff --git a/dev-tools/maven/pom.xml.template
> b/dev-tools/maven/pom.xml.template
> index 4e21ca0e13..50299a3cda 100644
> --- a/dev-tools/maven/pom.xml.template
> +++ b/dev-tools/maven/pom.xml.template
> @@ -238,7 +238,6 @@
> true
> -Xdoclint:all
> -Xdoclint:-missing
> - -proc:none
>
>
>
> {code}
> The ant build is fine, its just the maven build which is affected.
--
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-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=16431447#comment-16431447
]
Karl Wright commented on LUCENE-8245:
-
Ok, this is the debug output of the now-failing test:
{code}
[junit4] Suite: org.apache.lucene.spatial3d.geom.GeoPolygonTest
[junit4] 1> Considering edge [lat=1.5463873005088208E-34, lon=0.0([X=1.0,
Y=0.0, Z=1.5463873005088208E-34])] -> [lat=-0.08842062843650192,
lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336,
Z=-0.08830545832969094])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=0.7779906922732096,
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598,
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0,
Z=1.5463873005088208E-34])]
[junit4] 1>
[junit4] 1> Considering edge [lat=-0.08842062843650192,
lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336,
Z=-0.08830545832969094])] -> [lat=0.379731892927642,
lon=2.3485766139444504([X=-0.651713420845267, Y=0.
6617191814215959, Z=0.370671474528177])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=0.7779906922732096,
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598,
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0,
Z=1.5463873005088208E-34])]
[junit4] 1>
[junit4] 1> Considering edge [lat=0.7779906922732096,
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598,
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0,
Z=1.5463873005088208E-34])]
[junit4] 1>
[junit4] 1> The following edges should intersect the travel/testpoint
planes:
[junit4] 1> Travel plane: [lat=0.7779906922732096,
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598,
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0,
Z=1.5463873005088208E-34])]
[junit4] 1>
[junit4] 1> start point travel dist=0.7018495564156595; end point travel
dist=-2.330673801245995E-13
[junit4] 1> start point travel above dist=0.7018495564176594; end point
travel above dist=1.7669326198754006E-12
[junit4] 1> start point travel below dist=0.7018495564136594; end point
travel below dist=-2.2330673801246E-12
[junit4] 1> start point testpoint dist=-0.4923642700993317; end point
testpoint dist=-0.7784765265847915
[junit4] 1> start point testpoint above dist=-0.49236427009733164; end
point testpoint above dist=-0.7784765265827914
[junit4] 1> start point testpoint below dist=-0.49236427010133177; end
point testpoint below dist=-0.7784765265867916
[junit4] 1> Travel inner point [X=1.0, Y=9.103203687613759E-13,
Z=2.2330673801246004E-12]; edgeplane=-1.0097419586828951E-28;
travelInsidePlane=4.0389678347315804E-28; edgestartplane=0.7579267927410742;
edgeendplane=-2.4114877353945626E-12
[junit4] 1> Edge added 1 to innerCrossingCount
[junit4] 1> Edge added 0 to outerCrossingCount
[junit4] FAILURE 0.16s | GeoPolygonTest.testAboveBelowCrossingDifferentEdges
<<<
[junit4]> Throwable #1: java.lang.AssertionError
[junit4]>at
org.apache.lucene.spatial3d.geom.GeoPolygonTest.testAboveBelowCrossingDifferentEdges(GeoPolygonTest.java:1486)
[junit4] Completed [1/1 (1!)] in 0.17s, 1 test, 1 failure <<< FAILURES!
{code}
> 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
>
>
> 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 planes and edges
> regardless if they are crossed by main plane. That fixed the above issue but
> shows other issues like travel planes crossing two edges when it should be
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 568 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/568/ Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC 5 tests failed. FAILED: org.apache.lucene.spatial.spatial4j.Geo3dShapeWGS84ModelRectRelationTest.testGeoPolygonRect Error Message: expected: but was: Stack Trace: java.lang.AssertionError: expected: but was: at __randomizedtesting.SeedInfo.seed([389CD4FDC599FC2D:587BE00A27B86BE]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.locationtech.spatial4j.shape.RandomizedShapeTest.randomPointIn(RandomizedShapeTest.java:250) at org.apache.lucene.spatial.spatial4j.ShapeRectRelationTestCase$3.generateRandomShape(ShapeRectRelationTestCase.java:133) at org.locationtech.spatial4j.shape.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:98) at org.apache.lucene.spatial.spatial4j.ShapeRectRelationTestCase.testGeoPolygonRect(ShapeRectRelationTestCase.java:157) 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.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.lucene.spatial.spatial4j.Geo3dShapeWGS
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 34 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/34/ 1 tests failed. FAILED: org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:52931/solr/MoveReplicaHDFSTest_failed_coll_true, https://127.0.0.1:47082/solr/MoveReplicaHDFSTest_failed_coll_true] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:52931/solr/MoveReplicaHDFSTest_failed_coll_true, https://127.0.0.1:47082/solr/MoveReplicaHDFSTest_failed_coll_true] at __randomizedtesting.SeedInfo.seed([B5BA6B803F8F7F6D:1F77B872885CAABD]: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(TestRuleAssertionsRequired.java:53) at org.apache
