[jira] [Created] (LUCENE-8898) TestRamUsageEstimator.testMap failures

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8898:


 Summary: TestRamUsageEstimator.testMap failures
 Key: LUCENE-8898
 URL: https://issues.apache.org/jira/browse/LUCENE-8898
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
 Fix For: 8.2


Here is an example failure:

{noformat}
4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([ED7055A14021EA69:CD56E1725ADAF91B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}

This happens on master and branch_8x but always when the JVM version is greater 
than or equal to 11 apparently.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: 

[jira] [Updated] (LUCENE-8898) TestRamUsageEstimator.testMap failures

[Adrien Grand (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand updated LUCENE-8898:
-
Issue Type: Bug  (was: Improvement)

> TestRamUsageEstimator.testMap failures
> --
>
> Key: LUCENE-8898
> URL: https://issues.apache.org/jira/browse/LUCENE-8898
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Blocker
> Fix For: 8.2
>
>
> Here is an example failure:
> {noformat}
> 4 tests failed.
> FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap
> Error Message:
> expected:<25152.0> but was:<30184.0>
> Stack Trace:
> java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
> at 
> __randomizedtesting.SeedInfo.seed([ED7055A14021EA69:CD56E1725ADAF91B]:0)
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:553)
> at org.junit.Assert.assertEquals(Assert.java:683)
> at 
> org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> 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:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> 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 
> 

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11.0.3) - Build # 803 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/803/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([357E97B4DBB41250:15582367C14F0122]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([357E97B4DBB41250:15582367C14F0122]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 

[jira] [Commented] (SOLR-13404) group.query doesn't work in distrib mode when group.format=simple

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876669#comment-16876669
 ] 

ASF subversion and git services commented on SOLR-13404:


Commit 00d931aaa727d3dcf2706f76e9a4938df12afc59 in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=00d931a ]

SOLR-13404: Fix NPE when group=true and no group.field is present

* This was introduced in SOLR-12249


> group.query doesn't work in distrib mode when group.format=simple
> -
>
> Key: SOLR-13404
> URL: https://issues.apache.org/jira/browse/SOLR-13404
> Project: Solr
>  Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13404.patch, SOLR-13404.patch
>
>
> While working on SOLR-12248, found that for group.query response is returned 
> only when group.format=grouped(default format) in distrib mode. For 
> group.main=true, request fails with AIOOE and for group.format=simple, no 
> grouped is returned



--
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-12249) Better error message when grouping on a tokenized (non SortableText) field in SolrCloud

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876670#comment-16876670
 ] 

ASF subversion and git services commented on SOLR-12249:


Commit 00d931aaa727d3dcf2706f76e9a4938df12afc59 in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=00d931a ]

SOLR-13404: Fix NPE when group=true and no group.field is present

* This was introduced in SOLR-12249


> Better error message when grouping on a tokenized (non SortableText) field in 
> SolrCloud
> ---
>
> Key: SOLR-12249
> URL: https://issues.apache.org/jira/browse/SOLR-12249
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.6.2, 8.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-12249.patch
>
>
> I didn't test this with master. Under the covers in stand-alone mode, the 
> "min" function is silently  substituted for the grouping, but that's not true 
> in SorlCloud mode. I broke this JIRA out separately to discuss whether it 
> _ever_ makes sense to group by a tokenized text field.
> Grouping by the min value in a field is at least consistent, but on a text 
> field I don't think it makes sense.
> I propose that we explicitly dis-allow this in both stand-alone and Cloud 
> mode, especially now that there's the SortableTextField.
> Comments?



--
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-12249) Better error message when grouping on a tokenized (non SortableText) field in SolrCloud

[Munendra S N (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1687#comment-1687
 ] 

Munendra S N commented on SOLR-12249:
-

[~erickerickson]
This introduced NPE when no group.field is specified. I'm not sure why the test 
cases for group.query didn't catch it

> Better error message when grouping on a tokenized (non SortableText) field in 
> SolrCloud
> ---
>
> Key: SOLR-12249
> URL: https://issues.apache.org/jira/browse/SOLR-12249
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.6.2, 8.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-12249.patch
>
>
> I didn't test this with master. Under the covers in stand-alone mode, the 
> "min" function is silently  substituted for the grouping, but that's not true 
> in SorlCloud mode. I broke this JIRA out separately to discuss whether it 
> _ever_ makes sense to group by a tokenized text field.
> Grouping by the min value in a field is at least consistent, but on a text 
> field I don't think it makes sense.
> I propose that we explicitly dis-allow this in both stand-alone and Cloud 
> mode, especially now that there's the SortableTextField.
> Comments?



--
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-12249) Better error message when grouping on a tokenized (non SortableText) field in SolrCloud

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876665#comment-16876665
 ] 

ASF subversion and git services commented on SOLR-12249:


Commit 48b026d5eedcfa2090596639dd5282fac18db40a in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=48b026d ]

SOLR-13404: Fix NPE when group=true and no group.field is present

* This was introduced in SOLR-12249


> Better error message when grouping on a tokenized (non SortableText) field in 
> SolrCloud
> ---
>
> Key: SOLR-12249
> URL: https://issues.apache.org/jira/browse/SOLR-12249
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.6.2, 8.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-12249.patch
>
>
> I didn't test this with master. Under the covers in stand-alone mode, the 
> "min" function is silently  substituted for the grouping, but that's not true 
> in SorlCloud mode. I broke this JIRA out separately to discuss whether it 
> _ever_ makes sense to group by a tokenized text field.
> Grouping by the min value in a field is at least consistent, but on a text 
> field I don't think it makes sense.
> I propose that we explicitly dis-allow this in both stand-alone and Cloud 
> mode, especially now that there's the SortableTextField.
> Comments?



--
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-13404) group.query doesn't work in distrib mode when group.format=simple

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876664#comment-16876664
 ] 

ASF subversion and git services commented on SOLR-13404:


Commit 48b026d5eedcfa2090596639dd5282fac18db40a in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=48b026d ]

SOLR-13404: Fix NPE when group=true and no group.field is present

* This was introduced in SOLR-12249


> group.query doesn't work in distrib mode when group.format=simple
> -
>
> Key: SOLR-13404
> URL: https://issues.apache.org/jira/browse/SOLR-13404
> Project: Solr
>  Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13404.patch, SOLR-13404.patch
>
>
> While working on SOLR-12248, found that for group.query response is returned 
> only when group.format=grouped(default format) in distrib mode. For 
> group.main=true, request fails with AIOOE and for group.format=simple, no 
> grouped is returned



--
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-8.1 - Build # 49 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/49/

8 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterThreadsToSegments.testSegmentCountOnFlushRandom

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([D563D606E1A2C66F]:0)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterThreadsToSegments

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([D563D606E1A2C66F]:0)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterThreadsToSegments

Error Message:
Captured an uncaught exception in thread: Thread[id=4748, name=Thread-4262, 
state=RUNNABLE, group=TGRP-TestIndexWriterThreadsToSegments]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4748, name=Thread-4262, state=RUNNABLE, 
group=TGRP-TestIndexWriterThreadsToSegments]
Caused by: java.lang.RuntimeException: 
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at __randomizedtesting.SeedInfo.seed([D563D606E1A2C66F]:0)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$2.run(TestIndexWriterThreadsToSegments.java:220)
Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexWriter is 
closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:681)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:695)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1591)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1213)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$2.run(TestIndexWriterThreadsToSegments.java:209)
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at __randomizedtesting.SeedInfo.seed([D563D606E1A2C66F]:0)
at 
org.apache.lucene.analysis.MockTokenizer.readChar(MockTokenizer.java:237)
at 
org.apache.lucene.analysis.MockTokenizer.readCodePoint(MockTokenizer.java:203)
at 
org.apache.lucene.analysis.MockTokenizer.incrementToken(MockTokenizer.java:164)
at 
org.apache.lucene.analysis.MockTokenFilter.incrementToken(MockTokenFilter.java:80)
at 
org.apache.lucene.analysis.MockVariableLengthPayloadFilter.incrementToken(MockVariableLengthPayloadFilter.java:44)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:812)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:442)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:406)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:250)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594)
... 2 more


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterThreadsToSegments

Error Message:
Captured an uncaught exception in thread: Thread[id=4745, name=Thread-4259, 
state=RUNNABLE, group=TGRP-TestIndexWriterThreadsToSegments]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4745, name=Thread-4259, state=RUNNABLE, 
group=TGRP-TestIndexWriterThreadsToSegments]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at __randomizedtesting.SeedInfo.seed([D563D606E1A2C66F]:0)
at 
org.apache.lucene.analysis.MockTokenizer.readChar(MockTokenizer.java:237)
at 
org.apache.lucene.analysis.MockTokenizer.readCodePoint(MockTokenizer.java:203)
at 
org.apache.lucene.analysis.MockTokenizer.incrementToken(MockTokenizer.java:164)
at 
org.apache.lucene.analysis.MockTokenFilter.incrementToken(MockTokenFilter.java:80)
at 
org.apache.lucene.analysis.MockVariableLengthPayloadFilter.incrementToken(MockVariableLengthPayloadFilter.java:44)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:812)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:442)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:406)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:250)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594)
at 

[jira] [Reopened] (SOLR-13404) group.query doesn't work in distrib mode when group.format=simple

[Munendra S N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N reopened SOLR-13404:
-

Reopening it to fix few more things

> group.query doesn't work in distrib mode when group.format=simple
> -
>
> Key: SOLR-13404
> URL: https://issues.apache.org/jira/browse/SOLR-13404
> Project: Solr
>  Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13404.patch, SOLR-13404.patch
>
>
> While working on SOLR-12248, found that for group.query response is returned 
> only when group.format=grouped(default format) in distrib mode. For 
> group.main=true, request fails with AIOOE and for group.format=simple, no 
> grouped is returned



--
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-13204) ArrayIndexOutOfBoundsException in org/apache/solr/search/grouping/endresulttransformer/MainEndResultTransformer.java[36]

[Munendra S N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N resolved SOLR-13204.
-
   Resolution: Fixed
 Assignee: Munendra S N
Fix Version/s: 8.2

> ArrayIndexOutOfBoundsException in 
> org/apache/solr/search/grouping/endresulttransformer/MainEndResultTransformer.java[36]
> 
>
> Key: SOLR-13204
> URL: https://issues.apache.org/jira/browse/SOLR-13204
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v "URL_BUG"
> {noformat}
> Please check the issue description below to find the "URL_BUG" that will 
> allow you to reproduce the issue reported.
>Reporter: Marek
>Assignee: Munendra S N
>Priority: Minor
>  Labels: diffblue, newdev
> Fix For: 8.2
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> solr/films/select?group=true=true=true
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> ERROR (qtp689401025-18) [   x:films] o.a.s.s.HttpSolrCall 
> null:java.lang.ArrayIndexOutOfBoundsException: 0
>   at 
> org.apache.solr.search.grouping.endresulttransformer.MainEndResultTransformer.transform(MainEndResultTransformer.java:36)
>   at 
> org.apache.solr.handler.component.QueryComponent.groupedFinishStage(QueryComponent.java:638)
>   at 
> org.apache.solr.handler.component.QueryComponent.finishStage(QueryComponent.java:601)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:432)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   [...]
> {noformat}
> There is accessed the first element of an empty array of strings, stored in 
> the member 'org.apache.solr.search.grouping.GroupingSpecification.fields'. 
> There is an attept to put some strings to the array at 
> org/apache/solr/handler/component/QueryComponent.java[283]; however, the 
> string "group.field" is not present in params of the processed 
> org.apache.solr.request.SolrQueryRequest instance.
> Look into section 'Environment' above to see installation step of Solr and 
> films collection.
> We found this issue and ~70 more like this using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. Find more 
> information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



--
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: 

[jira] [Created] (SOLR-13596) Remove deprecated grouping methods

[Munendra S N (JIRA)]

Munendra S N created SOLR-13596:
---

 Summary: Remove deprecated grouping methods
 Key: SOLR-13596
 URL: https://issues.apache.org/jira/browse/SOLR-13596
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Munendra S N


As part of SOLR-9660, few of the methods in GroupingSpecification are 
deprecated. Remove these methods and their usages



--
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-4181) grouping response format inconsistent in distributed search when no docs match group.query

[Munendra S N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N resolved SOLR-4181.

   Resolution: Fixed
 Assignee: Munendra S N
Fix Version/s: 8.2

> grouping response format inconsistent in distributed search when no docs 
> match group.query
> --
>
> Key: SOLR-4181
> URL: https://issues.apache.org/jira/browse/SOLR-4181
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.2
>
>
> if a group.query does not match any documents, then in distribued search 
> (aka: solrcloud) that group.query will be completley excluded frm the final 
> result.
> This is inconsistent with single node grouping behavior, where the 
> group.query will be included in the final result (in the orde that it's pat 
> of the request) with a numFound=0



--
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-BadApples-master-Linux (64bit/jdk-11.0.3) - Build # 227 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/227/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([B07BE234E0248529:905D56E7FADF965B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test

Error Message:
Error from server at http://127.0.0.1:38951/collection1: non ok status: 500, 
message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38951/collection1: non ok status: 500, 
message:Server Error
at 
__randomizedtesting.SeedInfo.seed([E1FB01E12A0B3A66:69AF3E3B84F7579E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:586)

[jira] [Updated] (SOLR-13404) group.query doesn't work in distrib mode when group.format=simple

[Munendra S N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N updated SOLR-13404:

   Resolution: Fixed
 Assignee: Munendra S N
Fix Version/s: 8.2
   Status: Resolved  (was: Patch Available)

> group.query doesn't work in distrib mode when group.format=simple
> -
>
> Key: SOLR-13404
> URL: https://issues.apache.org/jira/browse/SOLR-13404
> Project: Solr
>  Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13404.patch, SOLR-13404.patch
>
>
> While working on SOLR-12248, found that for group.query response is returned 
> only when group.format=grouped(default format) in distrib mode. For 
> group.main=true, request fails with AIOOE and for group.format=simple, no 
> grouped is returned



--
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-13404) group.query doesn't work in distrib mode when group.format=simple

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876628#comment-16876628
 ] 

ASF subversion and git services commented on SOLR-13404:


Commit d811f8634252c9567966dc64482ff3bd2abb69ad in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d811f86 ]

SOLR-13404: support group.query in multishard env with group.main=true

group.query after execution forms QueryCommandResult. In case of
group.main=true or group.format=simple, QueryCommandResult was not
consumed in EndResultTransformer. Also, MainEndResultTransformer assumed
that always group.field would be specified. When group.field not specified
it failed with AIOOBE. After adding suppport for QueryCommandResult in
EndResultTransformers and handling AIOOBE, group.query started giving results

Working on tests exposed few other issues. Results differed b/w standalone
& distributed mode.
* One of the reason is that TopGroupShardResponseProcessor doesn't consider 
correct
  limit and offset when group format is simple. In case of simple, start and 
rows should be used
  as limit and offset instead of group.limit and group.offset.
* Secondly, In distributed second phase grouping, computing docsToCollect 
didn't consider
  group response format. This issue is again similar to above issue
* offset(group.offset or start) not being considered during TopDocs#merge caused
  different results. The fix was to use to offset in merge process
* group.offset doesn't support negative values but there is no checks on the 
value.
  In case of negative values AIOOBE. Now, checks are added for negative values 
and
  returns proper error message(this change is for both standalone and 
distrbuted).
  Validation is done only in case of group.format=grouped as that is only case 
when
  group.offset is consumed.

Fixing above issues resolved the differences b/w standalone and distributed 
mode.


> group.query doesn't work in distrib mode when group.format=simple
> -
>
> Key: SOLR-13404
> URL: https://issues.apache.org/jira/browse/SOLR-13404
> Project: Solr
>  Issue Type: Bug
>Reporter: Munendra S N
>Priority: Major
> Attachments: SOLR-13404.patch, SOLR-13404.patch
>
>
> While working on SOLR-12248, found that for group.query response is returned 
> only when group.format=grouped(default format) in distrib mode. For 
> group.main=true, request fails with AIOOE and for group.format=simple, no 
> grouped is returned



--
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-13404) group.query doesn't work in distrib mode when group.format=simple

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876619#comment-16876619
 ] 

ASF subversion and git services commented on SOLR-13404:


Commit cfd22cd493d3b0feab8f582b6981cc05ee4f31a3 in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cfd22cd ]

SOLR-13404: support group.query in multishard env with group.main=true

group.query after execution forms QueryCommandResult. In case of
group.main=true or group.format=simple, QueryCommandResult was not
consumed in EndResultTransformer. Also, MainEndResultTransformer assumed
that always group.field would be specified. When group.field not specified
it failed with AIOOBE. After adding suppport for QueryCommandResult in
EndResultTransformers and handling AIOOBE, group.query started giving results

Working on tests exposed few other issues. Results differed b/w standalone
& distributed mode.
* One of the reason is that TopGroupShardResponseProcessor doesn't consider 
correct
  limit and offset when group format is simple. In case of simple, start and 
rows should be used
  as limit and offset instead of group.limit and group.offset.
* Secondly, In distributed second phase grouping, computing docsToCollect 
didn't consider
  group response format. This issue is again similar to above issue
* offset(group.offset or start) not being considered during TopDocs#merge caused
  different results. The fix was to use to offset in merge process
* group.offset doesn't support negative values but there is no checks on the 
value.
  In case of negative values AIOOBE. Now, checks are added for negative values 
and
  returns proper error message(this change is for both standalone and 
distrbuted).
  Validation is done only in case of group.format=grouped as that is only case 
when
  group.offset is consumed.

Fixing above issues resolved the differences b/w standalone and distributed 
mode.


> group.query doesn't work in distrib mode when group.format=simple
> -
>
> Key: SOLR-13404
> URL: https://issues.apache.org/jira/browse/SOLR-13404
> Project: Solr
>  Issue Type: Bug
>Reporter: Munendra S N
>Priority: Major
> Attachments: SOLR-13404.patch, SOLR-13404.patch
>
>
> While working on SOLR-12248, found that for group.query response is returned 
> only when group.format=grouped(default format) in distrib mode. For 
> group.main=true, request fails with AIOOE and for group.format=simple, no 
> grouped is returned



--
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-8.x-Windows (64bit/jdk-11.0.3) - Build # 343 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/343/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseG1GC

19 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([5B1B8F8D4E27248B:7B3D3B5E54DC37F9]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([5B1B8F8D4E27248B:7B3D3B5E54DC37F9]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24328 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24328/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([ED7055A14021EA69:CD56E1725ADAF91B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([ED7055A14021EA69:CD56E1725ADAF91B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 

RE: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs

[Chris Hostetter]

Uwe: when you upgraded the JVMs, were there by any chance other 
(potentially inadvertent) changes to the VMs -- particularly the Windows 
VM?

Since June 22nd, we've see ReplicationFactorTest fail in _almost_ every 
Windows build from your server, regardless of JVM version used, on 
both master and branch_8x -- and when it fails, the failure repro 
checks at the end of the build "succeed" in reproducing the failure 
anywhere from 1-5 times.  All of the failures occur at the exact same line 
number of the test.

(Prior to June 22nd, this test only failed a total of 5 times in 2019, 
across all jenkins servers/OSes, etc... and at a quick glance, rarely in 
this specific spot)

Based on my review of a handful of the logs from the past week, it looks 
like the failures *may* be caused by CPU starvation -- but even that's a 
guess since similar situations are also tested earlier in the same test -- 
and it never seems to fail during them (as it simulates 3 servers with one 
or 2 of the replicas partitioned off via a closed proxy, one update thread 
on the leader is continuously trying to reconnect, while another leader 
thread is sending updates to the remaining "live" replica -- but that live 
replica doesn't seem to "see" the request until 30 seconds later, after 
the first update thread appears to have given up on the "down" replica)

in any case -- i'm wondering if perhaps the number of "virtual 
CPUs" or some other VM realted setting might have changed on your Windows 
test instance.



: Date: Sat, 22 Jun 2019 18:37:42 +0200
: From: Uwe Schindler 
: To: dev@lucene.apache.org, Chris Hostetter 
: Subject: RE: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs
: 
: Hi Hoss,
: 
:  
: 
: sorry for the delay, I updated JDK on Policeman Jenkins. But there are some 
things to mention:
: 
:  
: 
: * JDK 11.0.3 is *not* available free of charge from Oracle nor they 
supply OpenJDK convenience builds. Because of this we have to use JDK 11.0.3 
from AdoptOpenJDK (Hotspot variant). I have installed those builds on Linux, 
Windows, MacOSX
: * JDK 12.0.1 was also installed on Linux, Windows, MacOSX (also 
AdoptOpenJDK)
: * JDK 13-ea+26 was installed on Linux and Windows
: * JDK-13-ea+shipilev-fastdebug (nightly) was updated to yesterday’s 
build) on Linux
: 
:  
: 
: If the SSL errors are really coming from this and Users have to install 
11.0.3 at minimum, we have to mention this in release notes and on the web 
page. Especially we have to tell people to either pay Oracle to get 11.0.3 LTS 
or to use AdoptOpenJDK-Hotspot or Coretto (untested). Of course this is only a 
limitation if you enable TLS, which most people don’t do on their Solr servers.
: 
:  
: 
: Uwe
: 
:  
: 
: -
: 
: Uwe Schindler
: 
: Achterdiek 19, D-28357 Bremen
: 
: https://www.thetaphi.de
: 
: eMail: u...@thetaphi.de
: 
:  
: 
: From: Uwe Schindler  
: Sent: Saturday, June 22, 2019 10:19 AM
: To: Chris Hostetter 
: Cc: Lucene Dev 
: Subject: Re: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs
: 
:  
: 
: Ok, will work on it later today.
: 
: Uwe
: 
: Am June 22, 2019 12:23:17 AM UTC schrieb Chris Hostetter 
mailto:hossman_luc...@fucit.org> >:
: 
: 
: We also need to upgrade the jdk-13 jenkins jobs to at least 13-ea+26, 
: which includes the fix for JDK-8224829...
: 
:    
https://bugs.openjdk.java.net/browse/JDK-8224829
: 
: : Date: Tue, 18 Jun 2019 14:44:51 -0700 (MST)
: : From: Chris Hostetter <  
hossman_luc...@fucit.org>
: : To: Uwe Schindler <  u...@thetaphi.de>
: : Cc: Lucene Dev <  dev@lucene.apache.org>
: : Subject: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs
: : 
: : 
: : TL;DR: Uwe: can you please upgrade the jdk-11 used on the apache lucene 
jenkis
: : jobs and your policeman jenkins jobs to 11.0.3 ?
: : 
: : ---
: : 
: : Dat & I have (coincidently) found ourselves both looking into some (long
: : standing) SSL weirdness that has only ever manifested on java>=11.
: : 
: : Details can be found in SOLR-12988 & SOLR-12990 but the long and short of it
: : is there are at least 2 known OpenJDK bugs in SSL that have been fixed in
: : 11.0.3, which we are seeing evidence of in jenkins builds using 11.0.2
: : 
: :   
https://bugs.openjdk.java.net/browse/JDK-8213202
: :   
https://bugs.openjdk.java.net/browse/JDK-8212885 / JDK-8220723
: : 
: : (The nature of these bugs makes it hard -- at least AFAICT -- to try to 
write
: : any "assume" logic to auto-detect if they apply to the current JVM.)
: : 
: : There may in fact still be other SSL related bugs in jdk 11.0.3, but it will
: : be hard to know until we at least upgrade to 11.0.3 to see what still fails.
: : 
: : Uwe / whomever has access: if you could help us out here it 

[jira] [Commented] (SOLR-13589) Allow zplot to visualize 2D clusters and convex hulls

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876597#comment-16876597
 ] 

ASF subversion and git services commented on SOLR-13589:


Commit c6cc2fd9fd4f4f5e4b20f9b1c2eb3f04eda7cc7f in lucene-solr's branch 
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c6cc2fd ]

SOLR-13589: Allow zplot to visualize clusters and convex hulls


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch, clusters.png, 
> convex.png
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876598#comment-16876598
 ] 

ASF subversion and git services commented on SOLR-13589:


Commit 7e0df16220d2b4d6a867356bd488341dbedca58a in lucene-solr's branch 
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7e0df16 ]

SOLR-13589: Add zplot cluster test case


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch, clusters.png, 
> convex.png
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876599#comment-16876599
 ] 

ASF subversion and git services commented on SOLR-13589:


Commit 36ac878ea796105b0faa8992c44012522850f9a4 in lucene-solr's branch 
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=36ac878 ]

SOLR-13589: Fix precommit


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch, clusters.png, 
> convex.png
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876592#comment-16876592
 ] 

ASF subversion and git services commented on SOLR-13589:


Commit 2f6a681b3960bdf16426db89359f4484d58bdee3 in lucene-solr's branch 
refs/heads/master from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2f6a681 ]

SOLR-13589: Allow zplot to visualize clusters and convex hulls


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch, clusters.png, 
> convex.png
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876593#comment-16876593
 ] 

ASF subversion and git services commented on SOLR-13589:


Commit 6a99151eae07b9d7cf0940ce2d0c41ac06c5ba55 in lucene-solr's branch 
refs/heads/master from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6a99151 ]

SOLR-13589: Add zplot cluster test case


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch, clusters.png, 
> convex.png
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876594#comment-16876594
 ] 

ASF subversion and git services commented on SOLR-13589:


Commit 96d11063a79efb05f876441fefffe1599f8b0b7d in lucene-solr's branch 
refs/heads/master from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=96d1106 ]

SOLR-13589: Fix precommit


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch, clusters.png, 
> convex.png
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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: Lucene/Solr 8.2.0

[Joel Bernstein]

I've got one issue that I'd like to get in (
https://issues.apache.org/jira/browse/SOLR-13589), which I should have
wrapped up in a day or two. +1 for around July 10th.

On Mon, Jul 1, 2019 at 5:14 PM Nicholas Knize  wrote:

> +1 for starting the 8.2 release process. I think it would be good to get
> the LUCENE-8632  feature
> into 8.2 along with the BKD improvements and changes in LUCENE-
>  and LUCENE-8896
> 
>
> Nicholas Knize, Ph.D., GISP
> Geospatial Software Guy  |  Elasticsearch
> Apache Lucene PMC Member and Committer
> nkn...@apache.org
>
>
> On Wed, Jun 26, 2019 at 9:34 AM Ignacio Vera  wrote:
>
>> Hi all,
>>
>> 8.1 has been released on May 16th and we have new features, enhancements
>> and fixes that are not released yet so I'd like to start thinking in
>> releasing Lucene/Solr 8.2.0.
>>
>> I can create the 8.2 branch in two weeks time (around July 10th) and
>> build the first RC by the end of that week if that works for everyone.
>> Please let me know if there are bug fixes that needs to be fixed in 8.2 and
>> might not be ready by then.
>>
>> Cheers,
>>
>> Ignacio
>>
>

[jira] [Commented] (SOLR-13583) Impossible to delete a collection with the same name as an existing alias

[Andrzej Bialecki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876577#comment-16876577
 ] 

Andrzej Bialecki  commented on SOLR-13583:
--

Sorry, it took longer than expected... the attached patch has the following 
changes:
 * it adds an optional boolean {{followAliases}} to collection-specific admin 
commands. This option defaults to false.
 * modifies collection commands to resolve aliases only when this flag is 
present and turned on (thus restoring the previous behavior, and also enabling 
admin access to the collections with names shadowed by aliases).
 * fixes a bunch of bugs where unresolved vs. resolved name was passed on to 
different stages of multi-stage commands (like create / delete / reindex 
collection).
 * adds a bunch of unit tests.

Additionally I manually verified that with this patch you can successfully 
execute the scenario from the description, and also that {{removeSource}} works 
correctly.

The patch is relative to master - the affected code is basically identical with 
regard to these changes, and it applies cleanly to branch_8x.

> Impossible to delete a collection with the same name as an existing alias
> -
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1, 8.1.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 8.1.2
>
> Attachments: SOLR-13583.patch
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that 
> they always resolve aliases by default. In most cases this is desireable 
> behavior but it also prevents executing commands on the collections that have 
> the same name as an existing alias (which usually points to a different 
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with 
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the 
> collection admin commands that specifies whether the command should attempt 
> resolving the provided name as an alias first. From the point of view of ease 
> of use this could be an opt-out option, from the point of view of data safety 
> this could be an opt-in option.



--
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-13583) Impossible to delete a collection with the same name as an existing alias

[Andrzej Bialecki (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrzej Bialecki  updated SOLR-13583:
-
Attachment: SOLR-13583.patch

> Impossible to delete a collection with the same name as an existing alias
> -
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1, 8.1.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 8.1.2
>
> Attachments: SOLR-13583.patch
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that 
> they always resolve aliases by default. In most cases this is desireable 
> behavior but it also prevents executing commands on the collections that have 
> the same name as an existing alias (which usually points to a different 
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with 
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the 
> collection admin commands that specifies whether the command should attempt 
> resolving the provided name as an alias first. From the point of view of ease 
> of use this could be an opt-out option, from the point of view of data safety 
> this could be an opt-in option.



--
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-13-ea+26) - Build # 8029 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8029/
Java: 64bit/jdk-13-ea+26 -XX:-UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([4D08217DAFAC9167:6D2E95AEB5578215]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:830)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([4D08217DAFAC9167:6D2E95AEB5578215]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24327 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24327/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([6F6AEEBBF580035E:4F4C5A68EF7B102C]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([6F6AEEBBF580035E:4F4C5A68EF7B102C]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 

[GitHub] [lucene-solr] thomaswoeckinger commented on issue #665: Fixes SOLR-13539

[GitBox]

thomaswoeckinger commented on issue #665: Fixes SOLR-13539
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-507443102
 
 
   > Ok. I was worried we'd miss 8.1.2, so I took your changes to 
AbstractEnumField, BinaryField, BoolField, and UUIDField and merged them in a 
much smaller commit of their own. (see here: 
[8242e6c](https://github.com/apache/lucene-solr/commit/8242e6ce1da141e5585c0a8cd7ffc5953c5bf035))
 This commit didn't include any of your test changes, unfortunately.
   > 
   > (I don't like to merge code without tests, but since I'd seen and run the 
tests you added in this PR specifically for those field types, and tested it 
manually, I felt pretty confident.)
   > 
   > Anyway, I'll take a look at 755 and run the tests later today. Since your 
latest test changes are over in 755, and the atomic-update related field 
changes have already been merged, is there a reason to keep this PR around? We 
could just work off of 755 and close this out, unless there's a reason you see 
to keep both 755 and 665 open?
   
   The only reason is that the related issues are depending on each other, so i 
think it is still more clear to do this whole stuff with the PR's #755 and 
#665. Rebasing should be no problem anyway.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9961) RestoreCore needs the option to download files in parallel.

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876525#comment-16876525
 ] 

Mikhail Khludnev commented on SOLR-9961:


Design would be: 
* {{BackupRepositoryFactory}} holds shared thread pool
* thread pool is injected into created {{BackupRepository}} optionally
* Restore (Backup) operation(s) uses dedicated operation {{listAll(path, 
lambda)}} or {{forEach(list/file, lambda)}}
* Repoes, which accepted thread pool, invoke the lambda in threads
* Lambda accepts a repository delegate and expected to operate with it. This 
delegate reuses HDFS and close/release it after it's done. 
WDYT?   

> RestoreCore needs the option to download files in parallel.
> ---
>
> Key: SOLR-9961
> URL: https://issues.apache.org/jira/browse/SOLR-9961
> Project: Solr
>  Issue Type: Improvement
>  Components: Backup/Restore
>Affects Versions: 6.2.1
>Reporter: Timothy Potter
>Priority: Major
> Attachments: SOLR-9961.patch, SOLR-9961.patch, SOLR-9961.patch, 
> SOLR-9961.patch
>
>
> My backup to cloud storage (Google cloud storage in this case, but I think 
> this is a general problem) takes 8 minutes ... the restore of the same core 
> takes hours. The restore loop in RestoreCore is serial and doesn't allow me 
> to parallelize the expensive part of this operation (the IO from the remote 
> cloud storage service). We need the option to parallelize the download (like 
> distcp). 
> Also, I tried downloading the same directory using gsutil and it was very 
> fast, like 2 minutes. So I know it's not the pipe that's limiting perf here.
> Here's a very rough patch that does the parallelization. We may also want to 
> consider a two-step approach: 1) download in parallel to a temp dir, 2) 
> perform all the of the checksum validation against the local temp dir. That 
> will save round trips to the remote cloud storage.



--
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: Welcome Kevin Risden to the PMC

[Nicholas Knize]

Congrats and welcome Kevin!

On Mon, Jul 1, 2019, 2:10 AM Christian Moen  wrote:

> Congratulations!
>
> On Thu, Jun 27, 2019 at 9:04 PM Jan Høydahl  wrote:
>
>> I am pleased to announce that Kevin Risden has accepted the PMC's
>> invitation to join.
>>
>> Welcome Kevin!
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Lucene/Solr 8.2.0

[Nicholas Knize]

+1 for starting the 8.2 release process. I think it would be good to get
the LUCENE-8632  feature
into 8.2 along with the BKD improvements and changes in LUCENE-
 and LUCENE-8896


Nicholas Knize, Ph.D., GISP
Geospatial Software Guy  |  Elasticsearch
Apache Lucene PMC Member and Committer
nkn...@apache.org


On Wed, Jun 26, 2019 at 9:34 AM Ignacio Vera  wrote:

> Hi all,
>
> 8.1 has been released on May 16th and we have new features, enhancements
> and fixes that are not released yet so I'd like to start thinking in
> releasing Lucene/Solr 8.2.0.
>
> I can create the 8.2 branch in two weeks time (around July 10th) and build
> the first RC by the end of that week if that works for everyone. Please let
> me know if there are bug fixes that needs to be fixed in 8.2 and might not
> be ready by then.
>
> Cheers,
>
> Ignacio
>

[jira] [Commented] (LUCENE-8876) EnglishMinimalStemmer does not implement s-stemmer paper correctly?

[Mark Harwood (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876507#comment-16876507
 ] 

Mark Harwood commented on LUCENE-8876:
--

I reached out the paper author, Donna Harman a while ago and she just replied 
as follows:
{quote}It has been a very long time since I have thought about S-stemmers.   
But looking at your examples of bees and employees, it seems to me that rule 3 
is the correct one because rule 2 would be prevented from firing. 
{quote}
 

Given her assertion that rule 3 should apply to "bees" then it looks like that 
this would make rule 2 entirely redundant.

> EnglishMinimalStemmer does not implement s-stemmer paper correctly?
> ---
>
> Key: LUCENE-8876
> URL: https://issues.apache.org/jira/browse/LUCENE-8876
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Reporter: Mark Harwood
>Priority: Minor
>
> The EnglishMinimalStemmer fails to stem ees suffixes like bees, trees and 
> employees.
> The [original 
> paper|[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.9828=rep1=pdf]]
>  has this table of rules:
> !https://user-images.githubusercontent.com/170925/59616454-5dc7d580-911c-11e9-80b0-c7a59458c5a7.png!
> The notes accompanying the table state :
> {quote}"the first applicable rule encountered is the only one used"
> {quote}
>  
> For the {{ees}} and {{oes}} suffixes I think EnglishMinimalStemmer 
> misinterpreted the rule logic and consequently {{bees != bee}} and {{tomatoes 
> != tomato}}. The {{oes}} and {{ees}} suffixes are left intact.
> "The first applicable rule" for {{ees}} could be interpreted as rule 2 or 3 
> in the table depending on if you take {{applicable}} to mean "the THEN part 
> of the rule has fired" or just that the suffix was referenced in the rule. 
> EnglishMinimalStemmer has assumed the latter and I think it should be the 
> former. We should fall through into rule 3 for {{ees}} and {{oes}} (remove 
> any trailing S). That's certainly the conclusion I came to independently 
> testing on real data.
> There are some additional changes I'd like to see in a plural stemmer but I 
> won't list them here - the focus should be making the code here match the 
> original paper it references.



--
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-13537) Build Status Badge in git README

[Jason Gerlowski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Gerlowski resolved SOLR-13537.

Resolution: Done

(I don't want to attach a "Fix Version" here, because this change will never 
make it into any shipped version of Solr, as it's developer README only)

> Build Status Badge in git README
> 
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple 
> Artifact Build Badge.png, Simple Artifact Build Badges.png, Single Line 
> Badges.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a 
> git-driven ecosystem, it would be helpful to see the status builds in the 
> README. This is a standard for many open source projects. I think one could 
> debate whether we should have a multi-line build badge visual in the README 
> because people need to know about the builds for various versions and 
> platforms in the case of Lucene/Solr because it is such a large and widely 
> used project, in a variety of environments. The badges not only celebrate 
> that fact, they support its persistence in the future with new developers who 
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each 
> platform, Linux, Windows, MacOSX, and Solaris.



--
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-8.x-Linux (64bit/jdk-12.0.1) - Build # 801 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/801/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionAddReplica

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:41179/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:41179/solr
at 
__randomizedtesting.SeedInfo.seed([7FAD3BE83D11B0FD:FF8D5EC62C52585B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.autoscaling.TestPolicyCloud.after(TestPolicyCloud.java:87)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

[jira] [Commented] (SOLR-13587) Close BackupRepository after every usage

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876440#comment-16876440
 ] 

Kevin Risden commented on SOLR-13587:
-

[~mkhludnev] - No I asked around and didn't seem to be any way to work around 
the HDFS close stuff. Would need to be fixed in Hadoop first.

> Close BackupRepository after every usage
> 
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I 
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in 
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore 
> operation to make sure that closing hdfs filesystem doesn't break it see 
> SOLR-9961 for the case.



--
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-8.x-MacOSX (64bit/jdk-11.0.3) - Build # 217 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/217/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([4E2386831298D40:24C48CBB2BD29E32]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 
org.apache.lucene.util.TestRamUsageEstimator.testMap(TestRamUsageEstimator.java:136)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.util.TestRamUsageEstimator.testMap

Error Message:
expected:<25152.0> but was:<30184.0>

Stack Trace:
java.lang.AssertionError: expected:<25152.0> but was:<30184.0>
at 
__randomizedtesting.SeedInfo.seed([4E2386831298D40:24C48CBB2BD29E32]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at 

[jira] [Created] (SOLR-13595) SolrCloud - "[not a shard request]" is returned when search request is short circuited

[gopikannan venugopalsamy (JIRA)]

gopikannan venugopalsamy created SOLR-13595:
---

 Summary: SolrCloud - "[not a shard request]" is returned when 
search request is short circuited
 Key: SOLR-13595
 URL: https://issues.apache.org/jira/browse/SOLR-13595
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: gopikannan venugopalsamy


 If the collection has only one shard/replica or in case when _route_ param 
points to the hosted core,  [shard] field in response is set to  "[not a shard 
request]". 
 
When short-circuiting in below code "shard.url" is not populated in request 
param.
 
[https://github.com/apache/lucene-solr/blob/301ea0e4624c2bd693fc034a801c4abb91cba299/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java#L405]
 
[http://localhost:8983/solr/collection1/selct?q=*:*=[shard]]



--
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-12554) Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param

[Munendra S N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N updated SOLR-12554:

   Resolution: Done
Fix Version/s: 8.2
   Status: Resolved  (was: Patch Available)

> Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param
> --
>
> Key: SOLR-12554
> URL: https://issues.apache.org/jira/browse/SOLR-12554
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Munendra S N
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-12554.patch, SOLR-12554.patch, SOLR-12554.patch, 
> SOLR-12554.patch, SOLR-12554.patch
>
>
> Currently, the RAMPerThreadHardLimitMB parameter of IWC is not exposed. This 
> is useful to control flush policies.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12554) Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876410#comment-16876410
 ] 

ASF subversion and git services commented on SOLR-12554:


Commit fc15cd79f7a107127e547075d56e82f6aea2830a in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fc15cd7 ]

SOLR-12554: Expose IndexWriterConfig's ramPerThreadHardLimitMB

* When ramPerThreadHardLimitMB is not specified, then Lucene's
  default value 1945 is used. The specified value should be
  greater than 0 and less than 2048MB


> Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param
> --
>
> Key: SOLR-12554
> URL: https://issues.apache.org/jira/browse/SOLR-12554
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12554.patch, SOLR-12554.patch, SOLR-12554.patch, 
> SOLR-12554.patch, SOLR-12554.patch
>
>
> Currently, the RAMPerThreadHardLimitMB parameter of IWC is not exposed. This 
> is useful to control flush policies.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12.0.1) - Build # 24326 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24326/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseG1GC

18 tests failed.
FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:34919/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:34919/solr
at 
__randomizedtesting.SeedInfo.seed([BE23171C4720FF0B:D43576CC2FD2B5C1]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:256)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

Re: BadApple report

[Kevin Risden]

HdfsAutoAddReplicasIntegrationTest.testSimple

I am going to awaitsfix this test -
https://issues.apache.org/jira/browse/SOLR-13338. I haven't had time to
look into recent failures. I thought the Jetty upgrade would have helped.
It had very similar timeout waiting exception.

Kevin Risden


On Mon, Jul 1, 2019 at 12:13 PM Erick Erickson 
wrote:

> Pretty steady, I won’t be doing anything with annotations this week:
>
>  **Annotations will be removed from the following tests because they
> haven't failed in the last 4 rollups.
>
>   **Methods: 3
>FullSolrCloudDistribCmdsTest.test
>MultiThreadedOCPTest.test
>SolrZkClientTest.testSimpleUpdateACLs
>
>
> Failures in Hoss' reports for the last 4 rollups.
>
> There were 585 unannotated tests that failed in Hoss' rollups. Ordered by
> the date I downloaded the rollup file, newest->oldest. See above for the
> dates the files were collected
> These tests were NOT BadApple'd or AwaitsFix'd
> All tests that failed 4 weeks running will be BadApple'd unless there are
> objections
>
> Failures in the last 4 reports..
>Report   Pct runsfails   test
>  0123   1.8  955 30
> AliasIntegrationTest.testClusterStateProviderAPI
>  0123   0.5  972207  BasicAuthIntegrationTest.testBasicAuth
>  0123  30.4   89 24
> HdfsAutoAddReplicasIntegrationTest.testSimple
>  0123   0.4  921 10  HttpPartitionTest.test
>  0123   0.9  924 12  NestedShardedAtomicUpdateTest.test
>  0123   0.5  908  5
> ReindexCollectionTest.testBasicReindexing
>  0123   0.9  928 12  RollingRestartTest.test
>  0123  12.0   90 11
> ShardSplitTest.testSplitWithChaosMonkey
>  0123   0.9  927  8
> SystemCollectionCompatTest.testBackCompat
>  0123   0.5  926 23
> TestFieldCacheRewriteMethod.testRegexps
>  0123   0.9  924 13
> TestSimpleSearchEquivalence.testBooleanBoostPropagation
>  0123   0.9  924 15
> TestSimpleSearchEquivalence.testBoostQuerySimplification
>  0123   0.4  924  8
> TestSimpleSearchEquivalence.testPhraseRelativePositions
>  0123   0.4  924  9
> TestSimpleSearchEquivalence.testSloppyPhraseRelativePositions
>  0123   1.8  908 14  TestTopDocsMerge.testSort_1
>  Will BadApple all tests above this line except ones listed at
> the top**
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-12554) Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876402#comment-16876402
 ] 

ASF subversion and git services commented on SOLR-12554:


Commit 0e877aac3480847c0b587c6909bb27ebfae8b7a0 in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0e877aa ]

SOLR-12554: Expose IndexWriterConfig's ramPerThreadHardLimitMB

* When ramPerThreadHardLimitMB is not specified, then Lucene's
  default value 1945 is used. The specified value should be
  greater than 0 and less than 2048MB


> Expose IndexWriterConfig's RAMPerThreadHardLimitMB as SolrConfig.xml param
> --
>
> Key: SOLR-12554
> URL: https://issues.apache.org/jira/browse/SOLR-12554
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-12554.patch, SOLR-12554.patch, SOLR-12554.patch, 
> SOLR-12554.patch, SOLR-12554.patch
>
>
> Currently, the RAMPerThreadHardLimitMB parameter of IWC is not exposed. This 
> is useful to control flush policies.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1886 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1886/

3 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsChaosMonkeyNothingIsSafeTest.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([F348A10294CFF974]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsChaosMonkeyNothingIsSafeTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([F348A10294CFF974]:0)


FAILED:  org.apache.solr.search.facet.TestJsonFacets.testErrors {p0=SMART}

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([F348A10294CFF974:256F899B165806A7]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.solr.search.facet.TestJsonFacets.doTestErrors(TestJsonFacets.java:3163)
at 
org.apache.solr.search.facet.TestJsonFacets.testErrors(TestJsonFacets.java:3150)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

[GitHub] [lucene-solr] nknize commented on a change in pull request #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries

[GitBox]

nknize commented on a change in pull request #726: LUCENE-8632: New XYShape 
Field and Queries for indexing and searching general cartesian geometries
URL: https://github.com/apache/lucene-solr/pull/726#discussion_r299156599
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/geo/XYRectangle2D.java
 ##
 @@ -0,0 +1,252 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.geo;
+
+import java.util.Arrays;
+
+import org.apache.lucene.index.PointValues.Relation;
+import org.apache.lucene.util.NumericUtils;
+
+import static java.lang.Integer.BYTES;
+import static org.apache.lucene.geo.GeoUtils.orient;
+import static org.apache.lucene.geo.XYEncodingUtils.decode;
+
+/**
+ * 2D rectangle implementation containing cartesian spatial logic.
+ *
+ * @lucene.internal
+ */
+public class XYRectangle2D {
 
 Review comment:
   Updated `XYRectangle2D` to derive from `Rectangle2D` Worked out quite nicely 
and eliminated nearly all duplicate code.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man resolved SOLR-12988.
-
Resolution: Workaround

With the jenkins servers upgraded, and the new SSLTestConfig assumptions in 
place i haven't seen any (obvious) signs of any other openJDK related SSL bugs 
in the solr tests ... if more are identified we can update the issue 
description to list them here.

I've also created SOLR-13594 to track the (eventual) need to enable SSL testing 
on java-13-ea once the known bugs are addressed (but fortunately, the way the 
supression logic is implemented, it explicitly checks for "ea" bbuilds ... so 
even if we never get a chance to proactively test on future java-13-ea builds, 
once java-13 final comes out, the tests _will_ try SSL on them automatically)

> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
>  Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
>  Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-12988.patch, 
> SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3 
> support was first added) that are known to affect Solr's SSL support, and 
> have caused numerous test failures -- notably early "testing" builds of 
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1, 
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to 
> mitigate these bugs, and have taken steps to ensure any code using our 
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed" 
> with an {{AssumptionViolatedException}} when used on JVMs that are known to 
> be problematic.
> Users who encounter any of the types of failures described below, or 
> developers who encounter test runs that "SKIP" with a message refering to 
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try 
> disabling "TLSv1.3" in your JVM security properties)
> 
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's 
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs 
> when making intra-node requests, with a root cause of 
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4]   2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer 
> not authenticated
>[junit4]   2>  at 
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4]   2>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4]   2>  at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4]   2>  at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May 

[jira] [Created] (SOLR-13594) re-enable j13-ea SSL testing once known bugs are fixed

[Hoss Man (JIRA)]

Hoss Man created SOLR-13594:
---

 Summary: re-enable j13-ea SSL testing once known bugs are fixed
 Key: SOLR-13594
 URL: https://issues.apache.org/jira/browse/SOLR-13594
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


SOLR-12988 tracks several known bugs affecting SSL usage in OpenJDK java-13-ea 
and builds.

at the moment, SSLTestConfig explicitly throws AssumptionViolatedException if 
it looks like tests are being run on _any_ java-13-ea build ... once the known 
bugs are addressed in OpenJDK, and new java-13-ea builds are released that 
address those bugs, we should patch SSLTestConfig to test those new EA builds, 
an assuming no other obvious bugs are identified:
* update the logic in SSLTestConfig to suppress SSL testing only on the 
java-13-ea build#s known to be problematic.
* update the jenkins JVMs to use the new EA builds



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] atris commented on issue #756: LUCENE-8896: Override default implementation of IntersectVisitor#visit(DocIDSetBuilder, byte[]) for several queries

[GitBox]

atris commented on issue #756: LUCENE-8896: Override default implementation of 
IntersectVisitor#visit(DocIDSetBuilder, byte[]) for several queries
URL: https://github.com/apache/lucene-solr/pull/756#issuecomment-507357330
 
 
   Yeah, it does. I misread the heading of your JIRA earlier (thought you want 
to override (int, byte[])).


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Atri Sharma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876378#comment-16876378
 ] 

Atri Sharma commented on LUCENE-8857:
-

[~jpountz] Ran ant test 5 times again: all came in clean:

 

I have raised a new PR with testGrouping fixes: 
[https://github.com/apache/lucene-solr/pull/757]

 

Can we merge it, if it looks fine?
{code:java}
junit4:tophints]  54.39s | 
org.apache.lucene.search.suggest.document.TestSuggestField
[junit4:tophints]  16.93s | 
org.apache.lucene.search.suggest.DocumentDictionaryTest
[junit4:tophints]  16.63s | 
org.apache.lucene.search.suggest.analyzing.FuzzySuggesterTest
[junit4:tophints]  16.42s | 
org.apache.lucene.search.suggest.fst.FSTCompletionTest

-check-totals:

common.test:

-check-totals:

test:

BUILD SUCCESSFUL
Total time: 45 minutes 8 seconds
f01898a404cf:lucene atris$ {code}

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] atris opened a new pull request #757: LUCENE-8857: Introduce Custom Tiebreakers in TopDocs#merge

[GitBox]

atris opened a new pull request #757: LUCENE-8857: Introduce Custom Tiebreakers 
in TopDocs#merge
URL: https://github.com/apache/lucene-solr/pull/757
 
 
   This commit introduces custom tiebreakers which allows users to
   specify custom tiebreakers when ordering hits to return. A
   default tiebreaker is introduced for tie breaking on shard index
   first and then docID.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8896) Override default implementation of IntersectVisitor#visit(DocIDSetBuilder, byte[]) for several queries

[Ignacio Vera (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876373#comment-16876373
 ] 

Ignacio Vera commented on LUCENE-8896:
--

[~atris] I am not sure what you mean, I have opened a PR with the change, hope 
it make sense to you.

> Override default implementation of IntersectVisitor#visit(DocIDSetBuilder, 
> byte[]) for several queries
> --
>
> Key: LUCENE-8896
> URL: https://issues.apache.org/jira/browse/LUCENE-8896
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In LUCENE-8885, it was introduced a new method on the {{IntersectsVisitor}} 
> interface. It contains a default implementation but queries can override it 
> and therefore benefit when there are several documents on a leaf associated 
> to the same point.
> In this issue the following queries are proposed to override the default 
> implementation
> * LatLonShapeQuery
> * RangeFieldQuery
> * LatLonPointInPolygonQuery
> * LatLonPointDistanceQuery
> * PointRangeQuery
> * PointInSetQuery



--
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-13593) Allow to specify analyzer components by their SPI names in schema definition

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876372#comment-16876372
 ] 

Varun Thacker commented on SOLR-13593:
--

{quote}I agree with this idea! Meanwhile I think the field type resolution 
should be treated in another issue.
{quote}
Make sense!

> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {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

[GitHub] [lucene-solr] iverase opened a new pull request #756: LUCENE-8896: Override default implementation of IntersectVisitor#visit(DocIDSetBuilder, byte[]) for several queries

[GitBox]

iverase opened a new pull request #756: LUCENE-8896: Override default 
implementation of IntersectVisitor#visit(DocIDSetBuilder, byte[]) for several 
queries
URL: https://github.com/apache/lucene-solr/pull/756
 
 
   The following queries have been implemented:
   
   - LatLonShapeQuery
   
   - RangeFieldQuery
   
   - LatLonPointInPolygonQuery
   
   - LatLonPointDistanceQuery
   
   - PointRangeQuery
   
   - PointInSetQuery


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8892) Missing closing parens in string representation of MultiBoolFunction

[Munendra S N (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876362#comment-16876362
 ] 

Munendra S N commented on LUCENE-8892:
--

Thanks [~fdiebold]

[~jpountz]
I don't have permissions to resolve the JIRA, could you please resolve this? 
Thanks in advance :)

> Missing closing parens in string representation of MultiBoolFunction
> 
>
> Key: LUCENE-8892
> URL: https://issues.apache.org/jira/browse/LUCENE-8892
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Florian Diebold
>Priority: Trivial
> Attachments: 0001-Fix-missing-parenthesis-in-MultiBoolFunction.patch, 
> LUCENE-8892.patch, SOLR-13514.patch
>
>
> The {{description}} function of {{MultiBoolFunction}} includes an open 
> parenthesis, but doesn't close it. This makes score explanations more 
> confusing than necessary sometimes.



--
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-8892) Missing closing parens in string representation of MultiBoolFunction

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876360#comment-16876360
 ] 

ASF subversion and git services commented on LUCENE-8892:
-

Commit c8190e9c3b7271c6a09fd5cfa079ce5d016fd00b in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8190e9 ]

LUCENE-8892: add missing closing parentheses in MultiBoolFunction's 
description()


> Missing closing parens in string representation of MultiBoolFunction
> 
>
> Key: LUCENE-8892
> URL: https://issues.apache.org/jira/browse/LUCENE-8892
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Florian Diebold
>Priority: Trivial
> Attachments: 0001-Fix-missing-parenthesis-in-MultiBoolFunction.patch, 
> LUCENE-8892.patch, SOLR-13514.patch
>
>
> The {{description}} function of {{MultiBoolFunction}} includes an open 
> parenthesis, but doesn't close it. This makes score explanations more 
> confusing than necessary sometimes.



--
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-7442) HttpClient replacement for HTTP/2.0

[Munendra S N (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N resolved SOLR-7442.

   Resolution: Done
Fix Version/s: 8.1

> HttpClient replacement for HTTP/2.0
> ---
>
> Key: SOLR-7442
> URL: https://issues.apache.org/jira/browse/SOLR-7442
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
>
> Given that it would take about a year for Apache HC's HttpClient to support 
> HTTP/2 (as per [~olegk] in SOLR-6865), adding this issue for exploring the 
> way forward. It would be preferable to move to HTTP/2 and be able to use 
> features like async http calls. Maybe we could look for alternatives to HC 
> HttpClient, (e.g. Jetty's HttpClient)?



--
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-7442) HttpClient replacement for HTTP/2.0

[Munendra S N (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876359#comment-16876359
 ] 

Munendra S N commented on SOLR-7442:


I'm marking this as resolved, please reopen if that is not the case

> HttpClient replacement for HTTP/2.0
> ---
>
> Key: SOLR-7442
> URL: https://issues.apache.org/jira/browse/SOLR-7442
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> Given that it would take about a year for Apache HC's HttpClient to support 
> HTTP/2 (as per [~olegk] in SOLR-6865), adding this issue for exploring the 
> way forward. It would be preferable to move to HTTP/2 and be able to use 
> features like async http calls. Maybe we could look for alternatives to HC 
> HttpClient, (e.g. Jetty's HttpClient)?



--
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-11.0.3) - Build # 5233 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5233/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseG1GC

21 tests failed.
FAILED:  org.apache.lucene.search.grouping.TestGrouping.testRandom

Error Message:
doc=168 wrong shard expected:<6> but was:<-1>

Stack Trace:
java.lang.AssertionError: doc=168 wrong shard expected:<6> but was:<-1>
at 
__randomizedtesting.SeedInfo.seed([D411008CDDDB3E47:A65D25836CBB8834]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.lucene.search.grouping.TestGrouping.verifyShards(TestGrouping.java:1135)
at 
org.apache.lucene.search.grouping.TestGrouping.testRandom(TestGrouping.java:1026)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)


FAILED:  org.apache.lucene.search.grouping.TestGrouping.testRandom

Error Message:
doc=168 wrong shard expected:<6> but was:<-1>

Stack Trace:
java.lang.AssertionError: doc=168 wrong shard expected:<6> but was:<-1>
at 
__randomizedtesting.SeedInfo.seed([D411008CDDDB3E47:A65D25836CBB8834]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 

Re: [JENKINS] Solr-reference-guide-8.x - Build # 3944 - Still Failing

[Cassandra Targett]

And the master job finished successfully (I checked and made sure it ran on the 
new server, and it did), so now I’ve backported the script change to branch_8x 
and updated the 8.x Ref Guide job to use the tag “git-websites” again. It just 
also finished successfully.

Thanks again Steve for your earlier help - I’ve let Infra know we’re all set in 
INFRA-18666.

Cassandra
On Jul 1, 2019, 10:27 AM -0500, Cassandra Targett , 
wrote:
> I pushed a change to master and updated the Ref Guide master build to use 
> “git-websites” again. I’ll monitor the next time it runs (~30 minutes from 
> now) to see what happens. If it works, I’ll backport the change to branch_8x.
>
> Cassandra
> On Jun 30, 2019, 3:13 PM -0500, Erick Erickson , 
> wrote:
> > AFAIC, just push it. Even if you do find a way to test it, we’d still 
> > potentially have something _else_ different between your test bed and 
> > websites2…..
> >
> > > On Jun 30, 2019, at 12:46 PM, Cassandra Targett  
> > > wrote:
> > >
> > > Thanks for filing those issues, Steve.
> > >
> > > The master branch Ref Guide build started failing this weekend with the 
> > > Ruby installation problem, so I pinned that build to “websites1” for now.
> > >
> > > I saw the comments in the INFRA issue about using a newer version of 
> > > Ruby, but wasn’t really sure how to test installing Ruby 2.5.1 instead. 
> > > Apparently Gavin tried it and it worked all right after he initialized 
> > > with the ant ivy-bootstrap target. Should I just commit the version 
> > > change to the script, or try to test it some more first (somehow)?
> > >
> > > Cassandra
> > > On Jun 27, 2019, 10:41 AM -0500, Steve Rowe , wrote:
> > > > INFRA JIRA for "websites2" problem: 
> > > > https://issues.apache.org/jira/browse/INFRA-18666
> > > >
> > > > JIRA to add GPG key download to the ref guide build script: 
> > > > https://issues.apache.org/jira/browse/SOLR-13582
> > > >
> > > > --
> > > > Steve
> > > >
> > > > > On Jun 27, 2019, at 10:50 AM, Steve Rowe  wrote:
> > > > >
> > > > > The 8.x ref guide builds are running on a node they've never run on 
> > > > > before: "websites2". The master ref guide builds are running on the 
> > > > > "websites1" node, which has not exhibited the same build problems. 
> > > > > Both nodes are pinned to label "git-websites", which can result in 
> > > > > builds on either the "websites1" node or the "websites2" node. AFAICT 
> > > > > there's some kind of routing based on the identity (name maybe?) of 
> > > > > the job, which results in effectively permanent assignment to either 
> > > > > one or the other node.
> > > > >
> > > > > I put the key download commands from the error message into the 8.x 
> > > > > job config and triggered a run. This enabled verification. But there 
> > > > > is now another problem related to RVM's installation of Ruby 2.3.3: 
> > > > > compilation is failing, with details in a log file on the "websites2" 
> > > > > machine, to which I don't have access. I'll contact Infra about it.
> > > > >
> > > > > In the meantime, I pinned the 8.x build to "websites1" and triggered 
> > > > > a build, which succeeded. I left in the key download commands, so 
> > > > > leaving them in permanently apparently wouldn't cause any trouble. 
> > > > > (I'll make an issue to modify our build script to include a check for 
> > > > > the keys and download them if they don't exist.)
> > > > >
> > > > > --
> > > > > Steve
> > > > >
> > > > > > On Jun 27, 2019, at 9:22 AM, Cassandra Targett 
> > > > > >  wrote:
> > > > > >
> > > > > > Thanks Steve, that makes sense. Let me know if there’s anything I 
> > > > > > can do to help.
> > > > > >
> > > > > > If possible, maybe the script could check for the keys and import 
> > > > > > them if not available? At the very least, maybe I should add 
> > > > > > something about this scenario to internal Ref Guide docs. I totally 
> > > > > > forgot this had happened before.
> > > > > >
> > > > > > Sorry, I didn’t mean to imply you needed to disable the 8.1 job - I 
> > > > > > forgot to mention I recently gave myself permissions to do that in 
> > > > > > Jenkins - but thank you for doing it.
> > > > > >
> > > > > > Cassandra
> > > > > > On Jun 27, 2019, 8:12 AM -0500, Steve Rowe , 
> > > > > > wrote:
> > > > > > > This has happened previously. Usually it's a new machine that has 
> > > > > > > never built the ref guide previously. IIRC there was an Infra 
> > > > > > > notice a couple days ago about one of the 2 machines used to 
> > > > > > > build the ref guide ("website1" OSLT) being taken offline. 
> > > > > > > Probably they put in place a replacement for it.
> > > > > > >
> > > > > > > In the past I've modified the job config to do what's suggested 
> > > > > > > in the error message: download the key to the new machine, 
> > > > > > > trigger a run, then comment out the key download in the job 
> > > > > > > config.
> > > > > > >
> > > > > > > I suppose we could always download the key on every run?
> > > > > 

[jira] [Commented] (LUCENE-8892) Missing closing parens in string representation of MultiBoolFunction

[Florian Diebold (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876353#comment-16876353
 ] 

Florian Diebold commented on LUCENE-8892:
-

Thanks!

> Missing closing parens in string representation of MultiBoolFunction
> 
>
> Key: LUCENE-8892
> URL: https://issues.apache.org/jira/browse/LUCENE-8892
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Florian Diebold
>Priority: Trivial
> Attachments: 0001-Fix-missing-parenthesis-in-MultiBoolFunction.patch, 
> LUCENE-8892.patch, SOLR-13514.patch
>
>
> The {{description}} function of {{MultiBoolFunction}} includes an open 
> parenthesis, but doesn't close it. This makes score explanations more 
> confusing than necessary sometimes.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876350#comment-16876350
 ] 

ASF subversion and git services commented on SOLR-13105:


Commit 894a221a177fad2896cb7f48b8871500fdb8dd1e in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=894a221 ]

SOLR-13105: Add new clusters image


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-8892) Missing closing parens in string representation of MultiBoolFunction

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876339#comment-16876339
 ] 

ASF subversion and git services commented on LUCENE-8892:
-

Commit dc16e2707b73b5aa0a280f7ac5c8b09efdfe5160 in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=dc16e27 ]

LUCENE-8892: add missing closing parentheses in MultiBoolFunction's 
description()


> Missing closing parens in string representation of MultiBoolFunction
> 
>
> Key: LUCENE-8892
> URL: https://issues.apache.org/jira/browse/LUCENE-8892
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Florian Diebold
>Priority: Trivial
> Attachments: 0001-Fix-missing-parenthesis-in-MultiBoolFunction.patch, 
> LUCENE-8892.patch, SOLR-13514.patch
>
>
> The {{description}} function of {{MultiBoolFunction}} includes an open 
> parenthesis, but doesn't close it. This makes score explanations more 
> confusing than necessary sometimes.



--
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-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Atri Sharma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876335#comment-16876335
 ] 

Atri Sharma commented on LUCENE-8857:
-

[~jpountz] I investigated this and it turned out to be a test limitation 
(testGrouping assumed that TopDocs.merge was setting the shard indices). It 
took a while to reproduce since it was the random test which was failing 
(thanks for providing the seed!) I have fixed the test and ran ant test a 
couple of times – it came in clean:

 

Can we push this in now?

 
{code:java}
[junit4:tophints]  49.54s | 
org.apache.lucene.search.suggest.document.TestSuggestField
[junit4:tophints]  21.55s | 
org.apache.lucene.search.suggest.analyzing.FuzzySuggesterTest
[junit4:tophints]  21.51s | 
org.apache.lucene.search.suggest.DocumentDictionaryTest
[junit4:tophints]  15.45s | org.apache.lucene.search.spell.TestSpellChecker

-check-totals:

common.test:

-check-totals:

test:

BUILD SUCCESSFUL
Total time: 49 minutes 49 seconds
f01898a404cf:lucene atris$ {code}
 

[~munendrasn] I am not too aware of Solr's internals, but looking at the error 
you pointed to, looks like that the test is not setting shard indices or hit 
indices. This points to an assumption in the test – that TopDocs.merge is 
setting the shard indices. Can you check
{code:java}
search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java{code}
where the TopDocs.merge call is done? We can set shard indices for all TopHits 
based on the QueryCommandResult they come from.

 

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
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-13587) Close BackupRepository after every usage

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876330#comment-16876330
 ] 

Lucene/Solr QA commented on SOLR-13587:
---

| (/) *{color:green}+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 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
7s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 58s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 31m 
45s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 51s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13587 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12973276/SOLR-13587.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 82bf957 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/475/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/475/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Close BackupRepository after every usage
> 
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I 
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in 
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore 
> operation to make sure that closing hdfs filesystem doesn't break it see 
> SOLR-9961 for the case.



--
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

BadApple report

[Erick Erickson]

Pretty steady, I won’t be doing anything with annotations this week:

 **Annotations will be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 3
   FullSolrCloudDistribCmdsTest.test
   MultiThreadedOCPTest.test
   SolrZkClientTest.testSimpleUpdateACLs


Failures in Hoss' reports for the last 4 rollups.

There were 585 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd
All tests that failed 4 weeks running will be BadApple'd unless there are 
objections

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   1.8  955 30  
AliasIntegrationTest.testClusterStateProviderAPI
 0123   0.5  972207  BasicAuthIntegrationTest.testBasicAuth
 0123  30.4   89 24  
HdfsAutoAddReplicasIntegrationTest.testSimple
 0123   0.4  921 10  HttpPartitionTest.test
 0123   0.9  924 12  NestedShardedAtomicUpdateTest.test
 0123   0.5  908  5  ReindexCollectionTest.testBasicReindexing
 0123   0.9  928 12  RollingRestartTest.test
 0123  12.0   90 11  ShardSplitTest.testSplitWithChaosMonkey
 0123   0.9  927  8  SystemCollectionCompatTest.testBackCompat
 0123   0.5  926 23  TestFieldCacheRewriteMethod.testRegexps
 0123   0.9  924 13  
TestSimpleSearchEquivalence.testBooleanBoostPropagation
 0123   0.9  924 15  
TestSimpleSearchEquivalence.testBoostQuerySimplification
 0123   0.4  924  8  
TestSimpleSearchEquivalence.testPhraseRelativePositions
 0123   0.4  924  9  
TestSimpleSearchEquivalence.testSloppyPhraseRelativePositions
 0123   1.8  908 14  TestTopDocsMerge.testSort_1
 Will BadApple all tests above this line except ones listed at the 
top**


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13589) Allow zplot to visualize 2D clusters and convex hulls

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-13589:
--
Attachment: convex.png
clusters.png

> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch, clusters.png, 
> convex.png
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-13589:
--
Description: 
This ticket will add support for visualization of convex hulls through the 
projectToBorder function and 2D clusters by adding the clusters parameter to 
the zplot function.

The *projectToBorder* function is a function that works together with the 
existing *convexHull* function. It takes two parameters:

1) A Convex Hull created by the *convexHull* function.

2) A matrix of 2D points to project to the border.

The projectToBorder function then projects each 2D point to the Convex Hull 
border and returns a matrix with these points.

Using this approach the border of a convex hull can be visualized in 
interesting ways.

Sample visualizations are attached.

  was:
This ticket will add support for visualization of convex hulls through the 
projectToBorder function and 2D clusters by adding the clusters parameter to 
the zplot function.

The *projectToBorder* function is a function that works together with the 
existing *convexHull* function. It takes two parameters:

1) A Convex Hull created by the *convexHull* function.

2) A matrix of 2D points to project to the border.

The projectToBorder function then projects each 2D point to the Convex Hull 
border and returns a matrix with these points.

Using this approach the border of a convex hull can be visualized in 
interesting ways.


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.
> Sample visualizations are attached.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-13589:
--
Description: 
This ticket will add support for visualization of convex hulls through the 
projectToBorder function and 2D clusters by adding the clusters parameter to 
the zplot function.

The *projectToBorder* function is a function that works together with the 
existing *convexHull* function. It takes two parameters:

1) A Convex Hull created by the *convexHull* function.

2) A matrix of 2D points to project to the border.

The projectToBorder function then projects each 2D point to the Convex Hull 
border and returns a matrix with these points.

Using this approach the border of a convex hull can be visualized in 
interesting ways.

  was:
This ticket will support for visualization of convex hulls through the 
projectToBorder function and 2D clusters by adding the clusters parameter to 
the zplot function.

The *projectToBorder* function is a function that works together with the 
existing *convexHull* function. It takes two parameters:

1) A Convex Hull created by the *convexHull* function.

2) A matrix of 2D points to project to the border.

The projectToBorder function then projects each 2D point to the Convex Hull 
border and returns a matrix with these points.

Using this approach the border of a convex hull can be visualized in 
interesting ways.


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch
>
>
> This ticket will add support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.



--
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-13589) Allow zplot to visualize 2D clusters and convex hulls

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-13589:
--
Description: 
This ticket will support for visualization of convex hulls through the 
projectToBorder function and 2D clusters by adding the clusters parameter to 
the zplot function.

The *projectToBorder* function is a function that works together with the 
existing *convexHull* function. It takes two parameters:

1) A Convex Hull created by the *convexHull* function.

2) A matrix of 2D points to project to the border.

The projectToBorder function then projects each 2D point to the Convex Hull 
border and returns a matrix with these points.

Using this approach the border of a convex hull can be visualized in 
interesting ways.

  was:
The *projectToBorder* function is a function that works together with the 
existing *convexHull* function. It takes two parameters:

1) A Convex Hull created by the *convexHull* function.

2) A matrix of 2D points to project to the border.

The projectToBorder function then projects each 2D point to the Convex Hull 
border and returns a matrix with these points.

Using this approach the border of a convex hull can be visualized in 
interesting ways.


> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch
>
>
> This ticket will support for visualization of convex hulls through the 
> projectToBorder function and 2D clusters by adding the clusters parameter to 
> the zplot function.
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija commented on issue #665: Fixes SOLR-13539

[GitBox]

gerlowskija commented on issue #665: Fixes SOLR-13539
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-507317359
 
 
   Ok.  I was worried we'd miss 8.1.2, so I took your changes to 
AbstractEnumField, BinaryField, BoolField, and UUIDField and merged them in a 
much smaller commit of their own. (see here: 
https://github.com/apache/lucene-solr/commit/8242e6ce1da141e5585c0a8cd7ffc5953c5bf035)
  This commit didn't include any of your test changes, unfortunately.
   
   (I don't like to merge code without tests, but since I'd seen and run the 
tests you added in this PR specifically for those field types, and tested it 
manually, I felt pretty confident.)
   
   Anyway, I'll take a look at 755 and run the tests later today.  Since your 
latest test changes are over in 755, and the atomic-update related field 
changes have already been merged, is there a reason to keep this PR around?  We 
could just work off of 755 and close this out, unless there's a reason you see 
to keep both 755 and 665 open?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-13589) Allow zplot to visualize 2D clusters and convex hulls

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-13589:
--
Summary: Allow zplot to visualize 2D clusters and convex hulls  (was: Add 
projectToBorder Stream Evaluator )

> Allow zplot to visualize 2D clusters and convex hulls
> -
>
> Key: SOLR-13589
> URL: https://issues.apache.org/jira/browse/SOLR-13589
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13589.patch, SOLR-13589.patch
>
>
> The *projectToBorder* function is a function that works together with the 
> existing *convexHull* function. It takes two parameters:
> 1) A Convex Hull created by the *convexHull* function.
> 2) A matrix of 2D points to project to the border.
> The projectToBorder function then projects each 2D point to the Convex Hull 
> border and returns a matrix with these points.
> Using this approach the border of a convex hull can be visualized in 
> interesting ways.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876271#comment-16876271
 ] 

ASF subversion and git services commented on SOLR-13105:


Commit fa543f34285d4e900684e1ff5a20ddeb1c51bcc4 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fa543f3 ]

SOLR-13105: Add clusters


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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] Solr-reference-guide-8.x - Build # 3944 - Still Failing

[Cassandra Targett]

I pushed a change to master and updated the Ref Guide master build to use 
“git-websites” again. I’ll monitor the next time it runs (~30 minutes from now) 
to see what happens. If it works, I’ll backport the change to branch_8x.

Cassandra
On Jun 30, 2019, 3:13 PM -0500, Erick Erickson , wrote:
> AFAIC, just push it. Even if you do find a way to test it, we’d still 
> potentially have something _else_ different between your test bed and 
> websites2…..
>
> > On Jun 30, 2019, at 12:46 PM, Cassandra Targett  
> > wrote:
> >
> > Thanks for filing those issues, Steve.
> >
> > The master branch Ref Guide build started failing this weekend with the 
> > Ruby installation problem, so I pinned that build to “websites1” for now.
> >
> > I saw the comments in the INFRA issue about using a newer version of Ruby, 
> > but wasn’t really sure how to test installing Ruby 2.5.1 instead. 
> > Apparently Gavin tried it and it worked all right after he initialized with 
> > the ant ivy-bootstrap target. Should I just commit the version change to 
> > the script, or try to test it some more first (somehow)?
> >
> > Cassandra
> > On Jun 27, 2019, 10:41 AM -0500, Steve Rowe , wrote:
> > > INFRA JIRA for "websites2" problem: 
> > > https://issues.apache.org/jira/browse/INFRA-18666
> > >
> > > JIRA to add GPG key download to the ref guide build script: 
> > > https://issues.apache.org/jira/browse/SOLR-13582
> > >
> > > --
> > > Steve
> > >
> > > > On Jun 27, 2019, at 10:50 AM, Steve Rowe  wrote:
> > > >
> > > > The 8.x ref guide builds are running on a node they've never run on 
> > > > before: "websites2". The master ref guide builds are running on the 
> > > > "websites1" node, which has not exhibited the same build problems. Both 
> > > > nodes are pinned to label "git-websites", which can result in builds on 
> > > > either the "websites1" node or the "websites2" node. AFAICT there's 
> > > > some kind of routing based on the identity (name maybe?) of the job, 
> > > > which results in effectively permanent assignment to either one or the 
> > > > other node.
> > > >
> > > > I put the key download commands from the error message into the 8.x job 
> > > > config and triggered a run. This enabled verification. But there is now 
> > > > another problem related to RVM's installation of Ruby 2.3.3: 
> > > > compilation is failing, with details in a log file on the "websites2" 
> > > > machine, to which I don't have access. I'll contact Infra about it.
> > > >
> > > > In the meantime, I pinned the 8.x build to "websites1" and triggered a 
> > > > build, which succeeded. I left in the key download commands, so leaving 
> > > > them in permanently apparently wouldn't cause any trouble. (I'll make 
> > > > an issue to modify our build script to include a check for the keys and 
> > > > download them if they don't exist.)
> > > >
> > > > --
> > > > Steve
> > > >
> > > > > On Jun 27, 2019, at 9:22 AM, Cassandra Targett 
> > > > >  wrote:
> > > > >
> > > > > Thanks Steve, that makes sense. Let me know if there’s anything I can 
> > > > > do to help.
> > > > >
> > > > > If possible, maybe the script could check for the keys and import 
> > > > > them if not available? At the very least, maybe I should add 
> > > > > something about this scenario to internal Ref Guide docs. I totally 
> > > > > forgot this had happened before.
> > > > >
> > > > > Sorry, I didn’t mean to imply you needed to disable the 8.1 job - I 
> > > > > forgot to mention I recently gave myself permissions to do that in 
> > > > > Jenkins - but thank you for doing it.
> > > > >
> > > > > Cassandra
> > > > > On Jun 27, 2019, 8:12 AM -0500, Steve Rowe , wrote:
> > > > > > This has happened previously. Usually it's a new machine that has 
> > > > > > never built the ref guide previously. IIRC there was an Infra 
> > > > > > notice a couple days ago about one of the 2 machines used to build 
> > > > > > the ref guide ("website1" OSLT) being taken offline. Probably they 
> > > > > > put in place a replacement for it.
> > > > > >
> > > > > > In the past I've modified the job config to do what's suggested in 
> > > > > > the error message: download the key to the new machine, trigger a 
> > > > > > run, then comment out the key download in the job config.
> > > > > >
> > > > > > I suppose we could always download the key on every run?
> > > > > >
> > > > > > I'll work on it later today.
> > > > > >
> > > > > > I'll go disable the 8.1 ref guide job now.
> > > > > >
> > > > > > --
> > > > > > Steve
> > > > > >
> > > > > > > On Jun 27, 2019, at 8:02 AM, Cassandra Targett 
> > > > > > >  wrote:
> > > > > > >
> > > > > > > This seems to be a persistent problem. It’s complaining about the 
> > > > > > > keys for checking the RVM download. Right now it’s the 8.x job 
> > > > > > > that’s failing (and 8.1, which needs to be disabled), but the 
> > > > > > > master branch build appears to be fine.
> > > > > > >
> > > > > > > The jenkins.build.ref.guide.sh does the build, and I note in 

[jira] [Commented] (SOLR-13539) Atomic Update Multivalue remove does not work for field types UUID, Enums, Bool and Binary

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876265#comment-16876265
 ] 

ASF subversion and git services commented on SOLR-13539:


Commit e50e9c34683cd1b439f717faff074f7fabe871a5 in lucene-solr's branch 
refs/heads/branch_8_1 from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e50e9c3 ]

SOLR-13539: Fix mv update of UUID, enum, bool and binary fields

Co-Authored-By: Thomas Wockinger


> Atomic Update Multivalue remove does not work for field types UUID, Enums, 
> Bool  and Binary
> ---
>
> Key: SOLR-13539
> URL: https://issues.apache.org/jira/browse/SOLR-13539
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7.2, 8.1, 8.1.1
>Reporter: Thomas Wöckinger
>Priority: Critical
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
>  This is related to following field types: UUID, Enums, Bool and Binary



--
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-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes

[Tomoko Uchida (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876255#comment-16876255
 ] 

Tomoko Uchida commented on LUCENE-8566:
---

I opened SOLR-13593 to allow to use SPI names in the Solr schema definition.

> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as 
> follows.
>  - withTokenizer(Class factory, String... params)
>  - withTokenizer(Class factory, 
> Map params)
>  - addTokenFilter(Class factory, String... 
> params)
>  - addTokenFilter(Class factory, 
> Map params)
>  - addCharFilter(Class factory, String... params)
>  - addCharFilter(Class factory, 
> Map params)
> Since the builder also has methods which take service names, it seems like 
> that above methods are unnecessary and a little bit misleading. Giving 
> symbolic names is preferable to implementation factory classes, but for now, 
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}} 
> annotations) and deleting them in the future releases? Those are called by 
> only test cases so deleting them should have no impact on current lucene/solr 
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I 
> missed some point. I'll close it.)



--
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-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Atri Sharma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876253#comment-16876253
 ] 

Atri Sharma commented on LUCENE-8857:
-

I did – I was not able to see any failures (probably due to seeds?). I will try 
with the seed in your command now.

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] nknize commented on a change in pull request #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries

[GitBox]

nknize commented on a change in pull request #726: LUCENE-8632: New XYShape 
Field and Queries for indexing and searching general cartesian geometries
URL: https://github.com/apache/lucene-solr/pull/726#discussion_r299084653
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/geo/XYRectangle2D.java
 ##
 @@ -0,0 +1,252 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.geo;
+
+import java.util.Arrays;
+
+import org.apache.lucene.index.PointValues.Relation;
+import org.apache.lucene.util.NumericUtils;
+
+import static java.lang.Integer.BYTES;
+import static org.apache.lucene.geo.GeoUtils.orient;
+import static org.apache.lucene.geo.XYEncodingUtils.decode;
+
+/**
+ * 2D rectangle implementation containing cartesian spatial logic.
+ *
+ * @lucene.internal
+ */
+public class XYRectangle2D {
 
 Review comment:
   I think that's a good idea. This class is pretty much just for API purposed 
so I'll tease out the common logic and just have `Rectangle2D` derive what's 
common and implement the dateline crossing logic separately. Each constructor 
can handle their own encoding.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] iverase commented on a change in pull request #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries

[GitBox]

iverase commented on a change in pull request #726: LUCENE-8632: New XYShape 
Field and Queries for indexing and searching general cartesian geometries
URL: https://github.com/apache/lucene-solr/pull/726#discussion_r299084238
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/geo/XYPolygon2D.java
 ##
 @@ -0,0 +1,44 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.geo;
+
+/**
+ * 2D cartesian polygon implementation represented as a balanced interval tree 
of edges.
+ *
+ * @lucene.internal
+ */
+public class XYPolygon2D extends Polygon2D {
+
+  protected XYPolygon2D(XYPolygon polygon, XYPolygon2D holes) {
 
 Review comment:
   I see, good call. 
   
   I am gearing towards the idea that if we are going to have a spatial module, 
we should move everything there (even LatLonPoint). It is strange to have 
classes in two different places.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876248#comment-16876248
 ] 

Adrien Grand commented on LUCENE-8857:
--

[~atris] Can you look into those failures? I had understood from your comment 
on the PR that you had run tests? FYI I'm seeing issues on the Lucene end as 
well, e.g. ant test  -Dtestcase=TestGrouping -Dtests.method=testRandom 
-Dtests.seed=1039BE5B957F7FDD -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=be -Dtests.timezone=Europe/Rome -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8.

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
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-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876247#comment-16876247
 ] 

Tomoko Uchida commented on SOLR-13593:
--

This issue does not intend to replace current "class=...", of course, but 
provide alternative way to describe the analyzer to users. (Possibly the 
replacement could be happen in the future version.)

> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {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-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876244#comment-16876244
 ] 

ASF subversion and git services commented on LUCENE-8857:
-

Commit 3f0ecfa9c467c336ed8583ba8a2f2d920beb8763 in lucene-solr's branch 
refs/heads/master from Adrien Grand
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3f0ecfa ]

Revert "LUCENE-8857: Introduce Custom Tiebreakers in TopDocs#merge (#734)"

This reverts commit e70b43c39a2070a72a50a3b47ab3b9d485cdd044.


> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
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-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876242#comment-16876242
 ] 

Adrien Grand commented on LUCENE-8857:
--

Thanks [~munendrasn] I'm reverting now.

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] nknize commented on a change in pull request #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries

[GitBox]

nknize commented on a change in pull request #726: LUCENE-8632: New XYShape 
Field and Queries for indexing and searching general cartesian geometries
URL: https://github.com/apache/lucene-solr/pull/726#discussion_r299080261
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/geo/XYPolygon2D.java
 ##
 @@ -0,0 +1,44 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.geo;
+
+/**
+ * 2D cartesian polygon implementation represented as a balanced interval tree 
of edges.
+ *
+ * @lucene.internal
+ */
+public class XYPolygon2D extends Polygon2D {
+
+  protected XYPolygon2D(XYPolygon polygon, XYPolygon2D holes) {
 
 Review comment:
   Yes, we can absolutely add this to `Polygon2D` but I think we'd only want to 
do that if we decide `XYShape` will live in `core`?  If we decide to put both 
`LatLonShape` and `XYShape` in the `spatial` module we'd have to subclass like 
this so core does not depend on classes in external modules.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] msokolov edited a comment on issue #753: LUCENE-8895: switch all FST usage to enable array-with-gaps encoding

[GitBox]

msokolov edited a comment on issue #753: LUCENE-8895: switch all FST usage to 
enable array-with-gaps encoding
URL: https://github.com/apache/lucene-solr/pull/753#issuecomment-507295712
 
 
   Based on feedback so far, this looks like a reasonable step. Also note 
latest commit removes unused `Util.getByOutput()` and related tests.
   
   By the way, in addition to test and precommit, I also ran `ant test  
-Dtests.postingsformat=FST50` since that uncovered some issues previously.
   
   I'll push in a couple of days if there are no further comments. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] msokolov edited a comment on issue #753: LUCENE-8895: switch all FST usage to enable array-with-gaps encoding

[GitBox]

msokolov edited a comment on issue #753: LUCENE-8895: switch all FST usage to 
enable array-with-gaps encoding
URL: https://github.com/apache/lucene-solr/pull/753#issuecomment-507295712
 
 
   Based on feedback so far, this looks like a reasonable step. Also note 
latest commit removes unused `Util.getByOutput()` and related tests.
   
   By the way, in addition to test and precommit, I also ran {{ant test  
-Dtests.postingsformat=FST50}} since that uncovered some issues previously.
   
   I'll push in a couple of days if there are no further comments. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] [lucene-solr] msokolov commented on issue #753: LUCENE-8895: switch all FST usage to enable array-with-gaps encoding

[GitBox]

msokolov commented on issue #753: LUCENE-8895: switch all FST usage to enable 
array-with-gaps encoding
URL: https://github.com/apache/lucene-solr/pull/753#issuecomment-507295712
 
 
   Based on feedback so far, this looks like a reasonable step. Also note 
latest commit removes unused {{Util.getByOutput()}} and related tests.
   
   By the way, in addition to test and precommit, I also ran {{ant test  
-Dtests.postingsformat=FST50}} since that uncovered some issues previously.
   
   I'll push in a couple of days if there are no further comments. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876230#comment-16876230
 ] 

Tomoko Uchida commented on SOLR-13593:
--

[~varunthacker]: sorry, I made mistakes in my description. I fixed the 
attribute "class" to "name" in my example. I would prefer "name" for "SPI 
names" instead of "type". 

bq. Also should {{solr.TextField}} be just {{text}} ?

I agree with this idea! Meanwhile I think the field type resolution should be 
treated in another issue.

> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {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-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Munendra S N (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876227#comment-16876227
 ] 

Munendra S N commented on LUCENE-8857:
--

I'm working on SOLR-13404, after this merge som tests started failing. Just to 
be sure I tested in the latest master(without my changes), I was able to 
reproduce the failure

{code:java}
ant test  -Dtestcase=TestDistributedGrouping -Dtests.method=test 
-Dtests.seed=B5D95BEAE23E9468 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=nl-AW -Dtests.timezone=Asia/Jayapura -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
{code}

This is where it fails due to assertion Error
{code:java}
https://github.com/apache/lucene-solr/blob/e70b43c39a2070a72a50a3b47ab3b9d485cdd044/solr/core/src/test/org/apache/solr/TestDistributedGrouping.java#L329
{code}

{code:java}
https://github.com/apache/lucene-solr/blob/e70b43c39a2070a72a50a3b47ab3b9d485cdd044/lucene/core/src/java/org/apache/lucene/search/TopDocs.java#L79
{code}



> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch, LUCENE-8857.patch, 
> LUCENE-8857.patch, LUCENE-8857.patch
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12.0.1) - Build # 24325 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24325/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplicaLegacy

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:36343/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:36343/solr
at 
__randomizedtesting.SeedInfo.seed([BCB158A3A23A69EE:C5AB45B7340FF506]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplica(DeleteReplicaTest.java:384)
at 
org.apache.solr.cloud.DeleteReplicaTest.raceConditionOnDeleteAndRegisterReplicaLegacy(DeleteReplicaTest.java:264)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

[jira] [Comment Edited] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876223#comment-16876223
 ] 

Varun Thacker edited comment on SOLR-13593 at 7/1/19 2:33 PM:
--

+1 for having the ability to say "whitespace" etc

-Is the attribute called name or class? in your example the tokenizer has 
{{name=whitespace}} but the filter has- {{-class=keywordMarker.- Maybe 
}}{{type}} sounds better?

Also should {{solr.TextField}} be just {{text}} ?


was (Author: varunthacker):
+1 for having the ability to say "whitespace" etc

Is the attribute called name or class? in your example the tokenizer has 
{{name=whitespace}} but the filter has {{class=keywordMarker . Maybe }}{{type}} 
sounds better?

Also should {{solr.TextField}} be just {{text}} ?

> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876223#comment-16876223
 ] 

Varun Thacker commented on SOLR-13593:
--

+1 for having the ability to say "whitespace" etc

Is the attribute called name or class? in your example the tokenizer has 
{{name=whitespace}} but the filter has {{class=keywordMarker . Maybe }}{{type}} 
sounds better?

Also should {{solr.TextField}} be just {{text}} ?

> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {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] [Updated] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomoko Uchida updated SOLR-13593:
-
Description: 
Now each analysis factory has explicitely documented SPI name which is stored 
in the static "NAME" field (LUCENE-8778).
 Solr uses factories' simple class name in schema definition (like 
class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
more concise SPI names (like spi="whitespace").

e.g.:
{code:xml}

  



  

{code}
would be
{code:xml}

  



  

{code}

  was:
Now each analysis factory has explicitely documented SPI name which is stored 
in the static "NAME" field (LUCENE-8778).
 Solr uses factories' simple class name in schema definition (like 
class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
more concise SPI names (like name="whitespace").

e.g.:
{code:xml}

  



  

{code}
would be
{code:xml}

  



  

{code}


> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like spi="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {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] [Updated] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomoko Uchida updated SOLR-13593:
-
Description: 
Now each analysis factory has explicitely documented SPI name which is stored 
in the static "NAME" field (LUCENE-8778).
 Solr uses factories' simple class name in schema definition (like 
class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
more concise SPI names (like name="whitespace").

e.g.:
{code:xml}

  



  

{code}
would be
{code:xml}

  



  

{code}

  was:
Now each analysis factory has explicitely documented SPI name which is stored 
in the static "NAME" field (LUCENE-8778).
 Solr uses factories' simple class name in schema definition (like 
class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
more concise SPI names (like spi="whitespace").

e.g.:
{code:xml}

  



  

{code}
would be
{code:xml}

  



  

{code}


> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {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

[GitHub] [lucene-solr] nknize commented on a change in pull request #709: LUCENE-8850: Calculate the area of a polygon and throw error when values are invalid

[GitBox]

nknize commented on a change in pull request #709: LUCENE-8850: Calculate the 
area of a polygon and throw error when values are invalid
URL: https://github.com/apache/lucene-solr/pull/709#discussion_r299071383
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/geo/Polygon.java
 ##
 @@ -96,34 +99,50 @@ public Polygon(double[] polyLats, double[] polyLons, 
Polygon... holes) {
 this.holes = holes.clone();
 
 // compute bounding box
-double minLat = polyLats[0];
-double maxLat = polyLats[0];
-double minLon = polyLons[0];
-double maxLon = polyLons[0];
+double minLat = Double.POSITIVE_INFINITY;
+double maxLat = Double.NEGATIVE_INFINITY;
+double minLon = Double.POSITIVE_INFINITY;
+double maxLon = Double.NEGATIVE_INFINITY;
 
 double windingSum = 0d;
 final int numPts = polyLats.length - 1;
-for (int i = 1, j = 0; i < numPts; j = i++) {
+for (int i = 0; i < numPts; i++) {
   minLat = Math.min(polyLats[i], minLat);
   maxLat = Math.max(polyLats[i], maxLat);
   minLon = Math.min(polyLons[i], minLon);
   maxLon = Math.max(polyLons[i], maxLon);
   // compute signed area
-  windingSum += (polyLons[j] - polyLons[numPts])*(polyLats[i] - 
polyLats[numPts])
-  - (polyLats[j] - polyLats[numPts])*(polyLons[i] - polyLons[numPts]);
+  windingSum += polyLons[i] * polyLats[i + 1] - polyLats[i] * polyLons[i + 
1];
+}
+if (windingSum == 0) {
+  throw new IllegalArgumentException("Cannot compute the polygon / hole 
orientation.");
 }
 this.minLat = minLat;
 this.maxLat = maxLat;
 this.minLon = minLon;
 this.maxLon = maxLon;
 this.windingOrder = (windingSum < 0) ? GeoUtils.WindingOrder.CCW : 
GeoUtils.WindingOrder.CW;
+double area = Math.abs(windingSum / 2d);
+for (Polygon hole : holes) {
+  area -= hole.area();
+}
+if (area <= 0) {
+  throw new IllegalArgumentException("Polygon has an invalid area (area = 
" + area + ").");
+}
+this.area = area;
+
   }
 
   /** returns the number of vertex points */
   public int numPoints() {
 return polyLats.length;
   }
 
+  /** returns the area of the polygon */
+  public double area() {
 
 Review comment:
   > * Currently we compute the signed area to check the orientation of a 
polygon, if the area is 0 the polygon is considered CW, should we fail instead?
   
   +1 to fail in this situation since it is not a valid polygon. 
   
   
   > * I have seen polygons with one hole where the hole and polygon are the 
same, should we capture that situation and fail?
   
   +1 to fail in this situation as well. 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-8.x-Windows (32bit/jdk1.8.0_201) - Build # 342 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/342/
Java: 32bit/jdk1.8.0_201 -server -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.cloud.ReplicationFactorTest.test

Error Message:
Expected rf=2 because batch should have succeeded on 2 replicas (only one 
replica should be down) but got 1; clusterState: {   "control_collection":{ 
"pullReplicas":"0", "replicationFactor":"1", "shards":{"shard1":{   
  "range":"8000-7fff", "state":"active", 
"replicas":{"core_node2":{ 
"core":"control_collection_shard1_replica_n1", 
"base_url":"http://127.0.0.1:64826;, 
"node_name":"127.0.0.1:64826_", "state":"active", 
"type":"NRT", "leader":"true", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "nrtReplicas":"1", "tlogReplicas":"0"},   
"repfacttest_c8n_1x3":{ "pullReplicas":"0", "replicationFactor":"3",
 "shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node4":{ 
"core":"repfacttest_c8n_1x3_shard1_replica_n1", 
"base_url":"http://127.0.0.1:64900;, 
"node_name":"127.0.0.1:64900_", "state":"active", 
"type":"NRT", "leader":"true"},   "core_node5":{
 "core":"repfacttest_c8n_1x3_shard1_replica_n3", 
"base_url":"http://127.0.0.1:64826;, 
"node_name":"127.0.0.1:64826_", "state":"active", 
"type":"NRT"},   "core_node6":{ 
"core":"repfacttest_c8n_1x3_shard1_replica_n2", 
"base_url":"http://127.0.0.1:64860;, 
"node_name":"127.0.0.1:64860_", "state":"active", 
"type":"NRT", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"3",   
  "tlogReplicas":"0"},   "collection1":{ "pullReplicas":"0", 
"replicationFactor":"1", "shards":{   "shard1":{ 
"range":"8000-d554", "state":"active", 
"replicas":{"core_node5":{ "core":"collection1_shard1_replica_n3",  
   "base_url":"http://127.0.0.1:64900;, 
"node_name":"127.0.0.1:64900_", "state":"active", 
"type":"NRT", "leader":"true"}}},   "shard2":{ 
"range":"d555-2aa9", "state":"active", 
"replicas":{"core_node6":{ "core":"collection1_shard2_replica_n1",  
   "base_url":"http://127.0.0.1:64860;, 
"node_name":"127.0.0.1:64860_", "state":"active", 
"type":"NRT", "leader":"true"}}},   "shard3":{ 
"range":"2aaa-7fff", "state":"active", 
"replicas":{"core_node4":{ "core":"collection1_shard3_replica_n2",  
   "base_url":"http://127.0.0.1:64880;, 
"node_name":"127.0.0.1:64880_", "state":"active", 
"type":"NRT", "leader":"true", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "nrtReplicas":"1", "tlogReplicas":"0"}}

Stack Trace:
java.lang.AssertionError: Expected rf=2 because batch should have succeeded on 
2 replicas (only one replica should be down) but got 1; clusterState: {
  "control_collection":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"control_collection_shard1_replica_n1",
"base_url":"http://127.0.0.1:64826;,
"node_name":"127.0.0.1:64826_",
"state":"active",
"type":"NRT",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0"},
  "repfacttest_c8n_1x3":{
"pullReplicas":"0",
"replicationFactor":"3",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node4":{
"core":"repfacttest_c8n_1x3_shard1_replica_n1",
"base_url":"http://127.0.0.1:64900;,
"node_name":"127.0.0.1:64900_",
"state":"active",
"type":"NRT",
"leader":"true"},
  "core_node5":{
"core":"repfacttest_c8n_1x3_shard1_replica_n3",
"base_url":"http://127.0.0.1:64826;,
"node_name":"127.0.0.1:64826_",
"state":"active",
"type":"NRT"},
  "core_node6":{
"core":"repfacttest_c8n_1x3_shard1_replica_n2",
"base_url":"http://127.0.0.1:64860;,
"node_name":"127.0.0.1:64860_",
"state":"active",
"type":"NRT",

[jira] [Updated] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomoko Uchida updated SOLR-13593:
-
Description: 
Now each analysis factory has explicitely documented SPI name which is stored 
in the static "NAME" field (LUCENE-8778).
 Solr uses factories' simple class name in schema definition (like 
class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
more concise SPI names (like name="whitespace").

e.g.:
{code:xml}

  



  

{code}
would be
{code:xml}

  



  

{code}

  was:
Now each analysis factory has explicitely documented SPI names which is stored 
in the static "NAME" field (LUCENE-8778).
 Solr uses factories' simple class name in schema definition (like 
class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
more concise SPI names (like name="whitespace").

e.g.:
{code:xml}

  



  

{code}
would be
{code:xml}

  



  

{code}


> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

Tomoko Uchida created SOLR-13593:


 Summary: Allow to specify analyzer components by their SPI names 
in schema definition
 Key: SOLR-13593
 URL: https://issues.apache.org/jira/browse/SOLR-13593
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Reporter: Tomoko Uchida


Now each analysis factory has explicitely documented SPI names which is stored 
in the static "NAME" field (LUCENE-8778).
 Solr uses factories' simple class name in schema definition (like 
class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
more concise SPI names (like name="whitespace").

e.g.:
{code:xml}

  



  

{code}
would be
{code:xml}

  



  

{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