[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 138e206547f7a6732dc6dd56a516ad440256eaf0 in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=138e206 ]

LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 661fdf3a43e6d7a8b8b28254f69387209bafcd75 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=661fdf3 ]

LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12207:
-

Thanks, [~ab]. But now I'm challenged with the question which section it should 
go in. Is it a {{Bug Fix}} or oh,no {{Other}}? 

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12208) Don't use "INDEX.sizeInBytes" as a tag name in policy calculations

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-12208:


 Summary: Don't use "INDEX.sizeInBytes" as a tag name in policy 
calculations
 Key: SOLR-12208
 URL: https://issues.apache.org/jira/browse/SOLR-12208
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: AutoScaling
Reporter: Andrzej Bialecki 
Assignee: Noble Paul


CORE_IDX and FREEDISK ConditionType reuse this metric name, but they assume the 
values are expressed in gigabytes. This alone is confusing considering the name 
of the metric.

Additionally, it causes conflicts in the simulation framework that would 
require substantial changes to resolve (ReplicaInfo-s in 
SimClusterStateProvider keep metric values in their variables, expressed in 
original units - but then the Policy assumes it can put the values expressed in 
GB under the same key... hilarity ensues).



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12207:

Attachment: SOLR-12207.patch

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12207:
-

[~ab], all right. Agree. Here we go [^SOLR-12207.patch].

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12038) SPLITSHARD should check disk space before performing the operation

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12038:
--

As a part of SOLR-12181 I added a {{SplitShardSuggester}} but it's a very 
simplistic implementation - in particular it does NOT check the disk space 
needed for splitting.

> SPLITSHARD should check disk space before performing the operation
> --
>
> Key: SOLR-12038
> URL: https://issues.apache.org/jira/browse/SOLR-12038
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Noble Paul
>Priority: Major
>
> SPLITSHARD should first check if it has enough space to do the split before 
> it accepts the operation



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

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

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 569 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/569/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.cloud.TestConfigSetsAPI.testUpload

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:63507 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:63507 within 3 ms
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:183)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:102)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:232)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:195)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:122)
at 
org.apache.solr.cloud.TestConfigSetsAPI.setUp(TestConfigSetsAPI.java:115)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:968)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java: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 

[jira] [Updated] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-12187:

Attachment: SOLR-12187.patch

> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



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

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

[jira] [Comment Edited] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-12207 at 4/10/18 10:02 AM:
---

Turns out it brings a lot of noise on CI. [^SOLR-12207.patch] won't fix the 
issue, since 
[SolrPluginUtils.invokeSetters()|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/metrics/SolrMetricReporter.java#L61]
 goes with {{lenient=false}}. [~dawid.weiss], what about completely ignoring 
AssertionError at 
[ivokeSetters()|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L1011]
 since it's a jdk bug? 


was (Author: mkhludnev):
turns out it brings a lot of noise on CI

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-12207:


I'm not sure about ignoring AssertionError because, well, something went very 
wrong -- don't know if the application can recover to a reasonable state. 
Andrzej [~ab] would be probably a more authoritative person to tell. 

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 3a0aef1fe91039b397e4b023238fd0e0296459a3 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3a0aef1 ]

LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10) - Build # 21793 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21793/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
expected:<252> but was:<188>

Stack Trace:
java.lang.AssertionError: expected:<252> but was:<188>
at 
__randomizedtesting.SeedInfo.seed([FA03E6023D70D6DA:21A8E6C43858BF69]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:904)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
expected:<252> but was:<188>

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12207:
-

bq. I think we should start by adding more info to the error message so that we 
at least learn what class / setter / args cause this error, which may help us 
to come up with a workaround.
Ok. This is the only what [^SOLR-12207.patch] does. Going forward with it? 

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8245:
-

[~ivera], I've committed the tests with the @AwaitsFix annotation.  I'm looking 
at them one at a time.

Please let me turn your attention to "case2".  Debug output from this case 
looks like this:

{code}
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint 
planes:
   [junit4]   1> Travel plane: [lat=-0.09183481853716734, 
lon=0.0([X=0.9957861458099824, Y=0.0, Z=-0.09170578941866683])] -> 
[lat=-0.3728403971990659, lon=-0.27395646628085935([X=0.8965665862615776, 
Y=-0.25195523953197785, Z=-0.3642621496554991])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.09183481853716734, 
lon=0.0([X=0.9957861458099824, Y=0.0, Z=-0.09170578941866683])] -> 
[lat=-0.3728403971990659, lon=-0.27395646628085935([X=0.8965665862615776, 
Y=-0.25195523953197785, Z=-0.3642621496554991])]
   [junit4]   1>  Intersection found with travel plane...
   [junit4]   1>  Edge intersects travel or testPoint plane
   [junit4]   1>  Edge added 0 to innerCrossingCount
   [junit4]   1>  Edge added 1 to outerCrossingCount
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.28073906699213097, 
lon=0.21188006007761473([X=0.9393636799476138, Y=0.20206530496788694, 
Z=-0.2770658573760249])] -> [lat=-0.1600017188310958, 
lon=0.084975892731([X=0.983664825750331, Y=0.08378949178268695, 
Z=-0.1593199034909639])]
   [junit4]   1>  No intersections with travel plane...
   [junit4]   1>  No intersections with testpoint plane...
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.1600017188310958, 
lon=0.084975892731([X=0.983664825750331, Y=0.08378949178268695, 
Z=-0.1593199034909639])] -> [lat=-0.09183481853716734, 
lon=0.0([X=0.9957861458099824, Y=0.0, Z=-0.09170578941866683])]
   [junit4]   1>  No intersections with travel plane...
   [junit4]   1>  No intersections with testpoint plane...
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.3728403971990659, 
lon=-0.27395646628085935([X=0.8965665862615776, Y=-0.25195523953197785, 
Z=-0.3642621496554991])] -> [lat=-0.4683367913453203, 
lon=0.09620752412577895([X=0.8881938751251655, Y=0.08571555484949944, 
Z=-0.4514027955684197])]
   [junit4]   1>  No intersections with travel plane...
   [junit4]   1>  No intersections with testpoint plane... 
 
{code}

So, the sole edge that intersects with the travel plane does *not* intersect at 
either edge's endpoint; it intersects by virtue of an actual mathematical 
intersection being detected.  Since there is no detection of an intersection of 
the travel plane by any of the other edges, we can conclude, as you certainly 
have, that the edge's endpoints both lie outside of the zone where we would 
consider those endpoints to be on the travel plane.  So far, so good.  But 
let's be clear: this means, mathematically, that there is *no* intersection 
between any of the other edges and the travel plane.

What we need to do is figure out how the edge winds up crossing just one side 
of the envelope, and not exiting anywhere, without intersecting either the 
inner or outer envelope planes.  We know that intersection computation is not 
guaranteed to come up with a plane intersection unless there's an actual 
crossing of the plane within the intersection bounds.  So, probably, the 
endpoint's intersection with the inner/outer envelope plane(s) is what's being 
missed.

I'll try a fix and see how that does.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
> 

[jira] [Updated] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12207:

Summary: WildcardTypeImpl.getUpperBoundASTs AssertionError from 
SolrPluginUtils.invokeSetters   (was: jdk reflection AssertionError from 
SolrPluginUtils.invokeSetters )

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-repro - Build # 473 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/473/

[...truncated 35 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/556/consoleText

[repro] Revision: 7009f1cade6bd959d920aaaf819129b939e2f97a

[repro] Repro line:  ant test  -Dtestcase=TestSubQueryTransformerDistrib 
-Dtests.method=test -Dtests.seed=4831B4B32E31F316 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=sr-Latn-ME -Dtests.timezone=America/Edmonton 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
d45211d5344854ba68f9c5c344f6826aa18c5626
[repro] git fetch
[repro] git checkout 7009f1cade6bd959d920aaaf819129b939e2f97a

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestSubQueryTransformerDistrib
[repro] ant compile-test

[...truncated 3311 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestSubQueryTransformerDistrib" -Dtests.showOutput=onerror  
-Dtests.seed=4831B4B32E31F316 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sr-Latn-ME -Dtests.timezone=America/Edmonton 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[...truncated 1023 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   1/5 failed: 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib
[repro] git checkout d45211d5344854ba68f9c5c344f6826aa18c5626

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8245:
--

The problem why the plane enters the polygon and never exists is because it 
reaches the intersection point. The actual travel plane is just outside of the 
polygon running in paralell (never crosses) and only the inner plane enters 
until the intersection point is reached.

what we currently do is to check for crossing of all travel planes if either 
the test plane or the check plane has an intersections. Maybe we need to 
separate this logic.

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

Re: Potential BadApple report this week

[Shalin Shekhar Mangar]

Hi Erick,

You can go ahead and mark TestTriggerIntegration as BadApple. I don't think
anyone is working on it. I was working on TriggerIntegrationTest which is a
different test.

On Mon, Apr 9, 2018 at 10:02 PM, Erick Erickson 
wrote:

> OK, this is the first week I have Hoss' report from two weeks ago so
> the list is rather lengthy.
>
>
> I believe this test is being actively worked on, so no BadApple for it
>org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.
> testEventQueue
>
> ***Tests I'll BadApple on Thursday.
>
> These are tests that failed in the last week and _also_ are failures
> in Hoss' report from two weeks ago, so nobody has addressed them in
> that time-frame.
>
> PLEASE LET ME KNOW BEFORE THURSDAY WHICH OF THESE SHOULD NOT BE BADAPPLEd
>
>org.apache.lucene.index.TestIndexSorting.testRandom3
>org.apache.solr.TestDistributedSearch.test
>org.apache.solr.client.solrj.io.stream.StreamExpressionTest.
> testDistributions
>org.apache.solr.cloud.AddReplicaTest.test
>org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1
>org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test
>org.apache.solr.cloud.CreateRoutedAliasTest.
> testCollectionNamesMustBeAbsent
>org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate
>org.apache.solr.cloud.CreateRoutedAliasTest.testV1
>org.apache.solr.cloud.CreateRoutedAliasTest.testV2
>org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing
>org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupT
> est
>org.apache.solr.cloud.TestLeaderInitiatedRecoveryThr
> ead.testPublishDownState
>org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest
>org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloud
> Cluster.testCollectionCreateWithoutCoresThenDelete
>org.apache.solr.cloud.autoscaling.ComputePlanActionTest.
> testSelectedCollections
>org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger
>org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.
> testNodeAddedTriggerRestoreState
>org.apache.solr.common.cloud.TestCollectionStateWatchers.
> testDeletionsTriggerWatches
>org.apache.solr.handler.TestReplicationHandler.
> doTestIndexAndConfigReplication
>org.apache.solr.handler.TestReplicationHandler.
> doTestIndexFetchWithMasterUrl
>org.apache.solr.handler.TestReplicationHandler.
> doTestReplicateAfterCoreReload
>org.apache.solr.handler.TestReplicationHandler.doTestStressReplication
>org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory
>org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessor
> Test.test
>
>
> ***Tests currently BadApple-d
>
> *AwaitsFix Annotations:
>
>
> Lucene AwaitsFix
> TestControlledRealTimeReopenThread.java
>testCRTReopen()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5737
> ")
>
> TestICUNormalizer2CharFilter.java
>testRandomStrings()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5595
> ")
>
> TestMoreLikeThis.java
>testMultiFieldShouldReturnPerFieldBooleanQuery()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-7161
> ")
>
> UIMABaseAnalyzerTest.java
>testRandomStrings()
>@Test @AwaitsFix(bugUrl =
> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>
> UIMABaseAnalyzerTest.java
>testRandomStringsWithConfigurationParameters()
>@Test @AwaitsFix(bugUrl =
> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>
> UIMATypeAwareAnalyzerTest.java
>testRandomStrings()
>@Test @AwaitsFix(bugUrl =
> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>
>
> Solr AwaitsFix
> ReplaceNodeNoTargetTest.java
>ReplaceNodeNoTargetTest suite
>@LuceneTestCase.AwaitsFix(bugUrl =
> "https://issues.apache.org/jira/browse/SOLR-11067;)
>
> TestCollapseQParserPlugin.java
>testStringCollapse()
>@AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-11974;)
>
> TestImpersonationWithHadoopAuth.java
>testForwarding()
>@AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/HADOOP-9893;)
>
> TestLTRReRankingPipeline.java
>testDifferentTopN()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/SOLR-11134;)
>
> TestMinMaxOnMultiValuedField.java
>testDoubleFieldCache()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709
> ")
>
> TestMinMaxOnMultiValuedField.java
>testFloatFieldCache()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709
> ")
>
> TestMinMaxOnMultiValuedField.java
>testIntFieldCache()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709
> ")
>
> TestMinMaxOnMultiValuedField.java
>testLongFieldCache()
>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709
> ")
>
>
>
> 

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 197 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/197/

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState

Error Message:
The trigger did not fire at all

Stack Trace:
java.lang.AssertionError: The trigger did not fire at all
at 
__randomizedtesting.SeedInfo.seed([1D1E264F0B72E37F:9523AF3031B202D2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState(TestTriggerIntegration.java:379)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 13044 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-8231) Nori, a Korean analyzer based on mecab-ko-dic

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi commented on LUCENE-8231:
--

I attached a new patch that fixes an issue with offsets of the compound nouns. 
Currently the patch outputs a single path and can also keep the original 
compound as well as the decompounds. I think we can add the N best paths in a 
follow up.

> Nori, a Korean analyzer based on mecab-ko-dic
> -
>
> Key: LUCENE-8231
> URL: https://issues.apache.org/jira/browse/LUCENE-8231
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8231-remap-hangul.patch, LUCENE-8231.patch, 
> LUCENE-8231.patch, LUCENE-8231.patch, LUCENE-8231.patch, LUCENE-8231.patch, 
> LUCENE-8231.patch
>
>
> There is a dictionary similar to IPADIC but for Korean called mecab-ko-dic:
> It is available under an Apache license here:
> https://bitbucket.org/eunjeon/mecab-ko-dic
> This dictionary was built with MeCab, it defines a format for the features 
> adapted for the Korean language.
> Since the Kuromoji tokenizer uses the same format for the morphological 
> analysis (left cost + right cost + word cost) I tried to adapt the module to 
> handle Korean with the mecab-ko-dic. I've started with a POC that copies the 
> Kuromoji module and adapts it for the mecab-ko-dic.
> I used the same classes to build and read the dictionary but I had to make 
> some modifications to handle the differences with the IPADIC and Japanese. 
> The resulting binary dictionary takes 28MB on disk, it's bigger than the 
> IPADIC but mainly because the source is bigger and there are a lot of
> compound and inflect terms that define a group of terms and the segmentation 
> that can be applied. 
> I attached the patch that contains this new Korean module called -godori- 
> nori. It is an adaptation of the Kuromoji module so currently
> the two modules don't share any code. I wanted to validate the approach first 
> and check the relevancy of the results. I don't speak Korean so I used the 
> relevancy
> tests that was added for another Korean tokenizer 
> (https://issues.apache.org/jira/browse/LUCENE-4956) and tested the output 
> against mecab-ko which is the official fork of mecab to use the mecab-ko-dic.
> I had to simplify the JapaneseTokenizer, my version removes the nBest output 
> and the decomposition of too long tokens. I also
> modified the handling of whitespaces since they are important in Korean. 
> Whitespaces that appear before a term are attached to that term and this
> information is used to compute a penalty based on the Part of Speech of the 
> token. The penalty cost is a feature added to mecab-ko to handle 
> morphemes that should not appear after a morpheme and is described in the 
> mecab-ko page:
> https://bitbucket.org/eunjeon/mecab-ko
> Ignoring whitespaces is also more inlined with the official MeCab library 
> which attach the whitespaces to the term that follows.
> I also added a decompounder filter that expand the compounds and inflects 
> defined in the dictionary and a part of speech filter similar to the Japanese
> that removes the morpheme that are not useful for relevance (suffix, prefix, 
> interjection, ...). These filters don't play well with the tokenizer if it 
> can 
> output multiple paths (nBest output for instance) so for simplicity I removed 
> this ability and the Korean tokenizer only outputs the best path.
> I compared the result with mecab-ko to confirm that the analyzer is working 
> and ran the relevancy test that is defined in HantecRel.java included
> in the patch (written by Robert for another Korean analyzer). Here are the 
> results:
> ||Analyzer||Index Time||Index Size||MAP(CLASSIC)||MAP(BM25)||MAP(GL2)||
> |Standard|35s|131MB|.007|.1044|.1053|
> |CJK|36s|164MB|.1418|.1924|.1916|
> |Korean|212s|90MB|.1628|.2094|.2078|
> I find the results very promising so I plan to continue to work on this 
> project. I started to extract the part of the code that could be shared with 
> the
> Kuromoji module but I wanted to share the status and this POC first to 
> confirm that this approach is viable. The advantages of using the same model 
> than
> the Japanese analyzer are multiple: we don't have a Korean analyzer at the 
> moment ;), the resulting dictionary is small compared to other libraries that
> use the mecab-ko-dic (the FST takes only 5.4MB) and the Tokenizer prunes the 
> lattice on the fly to select the best path efficiently.
> The dictionary can be built directly from the godori module with the 
> following command:
> ant regenerate (you need to create the resource directory (mkdir 
> lucene/analysis/godori/src/resources/org/apache/lucene/analysis/ko/dict) 
> first since the dictionary is not 

[jira] [Updated] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12207:

Attachment: SOLR-12207.patch

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12207:
--

bq. This is the only what SOLR-12207.patch does
Well, it also ignores the assertion error when lenient == true, but the 
(undocumented ;) ) purpose of "lenient" was to only ignore non-fatal errors due 
to eg. missing or spurious config properties. However, this assertion error 
should be fatal because we can expect it leaves the component in half-baked 
state.

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2483 - Unstable

[Apache Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 76, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-12207:


We (in our code) had it appear randomly out of the blue, unfortunately. It 
wasn't reproducible (looked like a race condition).

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



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

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

[jira] [Comment Edited] (SOLR-11971) CVE-2018-1308: XXE attack through DIH's dataConfig request parameter

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-11971 at 4/10/18 11:30 AM:


Hi [~wunder],
as written in my announcement mail, there is no easy way to disable the 
"dataConfig"  parameter in running installations, unless you completely disable 
DIH. So your options are:
- disable DIH completely (yeah, not so nice)
- update to later version
- instruct your reverse proxy to remove "dataConfig" parameter before passing 
to Solr. I have seen configs for nginx doing similar things with the 
"stream.body" parameters.
- run Solr only on localhost
- install a firewall (that's a joke, you should have done this already)

One thing that might work (not sure yet):
- make dataConfig a "invariant" in solrconfig.xml. Does anybody know if this 
works for DIH, too?


was (Author: thetaphi):
Hi [~wunder],
as written in my announcement mail, there is no way to disable the "dataConfig" 
 parameter in running installations, unless you completely disable DIH. So your 
options are:
- disable DIH completely (yeah, not so nice)
- update to later version
- instruct your reverse proxy to remove "dataConfig" parameter before passing 
to Solr. I have seen configs for nginx doing similar things with the 
"stream.body" parameters.
- run Solr only on localhost
- install a firewall (that's a joke, you should have done this already)


> CVE-2018-1308: XXE attack through DIH's dataConfig request parameter
> 
>
> Key: SOLR-11971
> URL: https://issues.apache.org/jira/browse/SOLR-11971
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 6.6.3, 7.3, master (8.0)
>
> Attachments: ApacheSolrDIH-XXE.pdf, SOLR-11971.patch
>
>
> We got a security report about an XXE attack when using the 
> {{=}} of Solr's DataImportHandler. See the attached PDF 
> file with full details (I converted it to PDF, originally it was a DOC file).



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

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

[jira] [Resolved] (SOLR-12096) Inconsistent response format in subquery transform

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-12096.
-
Resolution: Fixed

> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch, 
> SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.testsubquery.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared 
> to single-shard
> h1. Single Shard collection
> Request 
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10001677",
> "score": 0.5,
> "_children_": {
> "numFound": 9,
> "start": 0,
> "docs": [
> {
> "uniqueId": "100016771",
> "score": 0.5
> },
> {
> "uniqueId": "100016772",
> "score": 0.5
> },
> {
> "uniqueId": "100016773",
> "score": 0.5
> }
> ]
> }
> }
> ]
> }
> }
> {code}
> Here, *_children_* suquery response is as expected (Based on documentation)
> h1. Multi Shard collection(2)
> Request
> {code:java}
> localhost:8983/solr/k_test_2/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> Response
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 11,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 5,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10006197",
> "_children_": [
> {
> "uniqueId": "100061971",
> "score": 0.5
> 

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12207:
-

turns out it brings a lot of noise on CI

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12207:
--

Catching this error just hides the bug and leaves the component possibly in a 
half-inited state. I think we should start by adding more info to the error 
message so that we at least learn what class / setter / args cause this error, 
which may help us to come up with a workaround.

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



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

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

[jira] [Comment Edited] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  edited comment on SOLR-12207 at 4/10/18 10:40 AM:


Catching this error just hides the bug and leaves the component possibly in a 
half-inited state. I think we should start by adding more info to the error 
message so that we at least learn what class / setter / args cause this error, 
which may help us to come up with a workaround.

(Edit) To clarify, I think this type of error should be fatal and the core 
should fail to load because we can't guarantee the proper initialization of 
components.


was (Author: ab):
Catching this error just hides the bug and leaves the component possibly in a 
half-inited state. I think we should start by adding more info to the error 
message so that we at least learn what class / setter / args cause this error, 
which may help us to come up with a workaround.

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-11971) CVE-2018-1308: XXE attack through DIH's dataConfig request parameter

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-11971:
--

Hi [~wunder],
as written in my announcement mail, there is no way to disable the "dataConfig" 
 parameter in running installations, unless you completely disable DIH. So your 
options are:
- disable DIH completely (yeah, not so nice)
- update to later version
- instruct your reverse proxy to remove "dataConfig" parameter before passing 
to Solr. I have seen configs for nginx doing similar things with the 
"stream.body" parameters.
- run Solr only on localhost
- install a firewall


> CVE-2018-1308: XXE attack through DIH's dataConfig request parameter
> 
>
> Key: SOLR-11971
> URL: https://issues.apache.org/jira/browse/SOLR-11971
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 6.6.3, 7.3, master (8.0)
>
> Attachments: ApacheSolrDIH-XXE.pdf, SOLR-11971.patch
>
>
> We got a security report about an XXE attack when using the 
> {{=}} of Solr's DataImportHandler. See the attached PDF 
> file with full details (I converted it to PDF, originally it was a DOC file).



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

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

[jira] [Updated] (LUCENE-8231) Nori, a Korean analyzer based on mecab-ko-dic

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi updated LUCENE-8231:
-
Attachment: LUCENE-8231.patch

> Nori, a Korean analyzer based on mecab-ko-dic
> -
>
> Key: LUCENE-8231
> URL: https://issues.apache.org/jira/browse/LUCENE-8231
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8231-remap-hangul.patch, LUCENE-8231.patch, 
> LUCENE-8231.patch, LUCENE-8231.patch, LUCENE-8231.patch, LUCENE-8231.patch, 
> LUCENE-8231.patch
>
>
> There is a dictionary similar to IPADIC but for Korean called mecab-ko-dic:
> It is available under an Apache license here:
> https://bitbucket.org/eunjeon/mecab-ko-dic
> This dictionary was built with MeCab, it defines a format for the features 
> adapted for the Korean language.
> Since the Kuromoji tokenizer uses the same format for the morphological 
> analysis (left cost + right cost + word cost) I tried to adapt the module to 
> handle Korean with the mecab-ko-dic. I've started with a POC that copies the 
> Kuromoji module and adapts it for the mecab-ko-dic.
> I used the same classes to build and read the dictionary but I had to make 
> some modifications to handle the differences with the IPADIC and Japanese. 
> The resulting binary dictionary takes 28MB on disk, it's bigger than the 
> IPADIC but mainly because the source is bigger and there are a lot of
> compound and inflect terms that define a group of terms and the segmentation 
> that can be applied. 
> I attached the patch that contains this new Korean module called -godori- 
> nori. It is an adaptation of the Kuromoji module so currently
> the two modules don't share any code. I wanted to validate the approach first 
> and check the relevancy of the results. I don't speak Korean so I used the 
> relevancy
> tests that was added for another Korean tokenizer 
> (https://issues.apache.org/jira/browse/LUCENE-4956) and tested the output 
> against mecab-ko which is the official fork of mecab to use the mecab-ko-dic.
> I had to simplify the JapaneseTokenizer, my version removes the nBest output 
> and the decomposition of too long tokens. I also
> modified the handling of whitespaces since they are important in Korean. 
> Whitespaces that appear before a term are attached to that term and this
> information is used to compute a penalty based on the Part of Speech of the 
> token. The penalty cost is a feature added to mecab-ko to handle 
> morphemes that should not appear after a morpheme and is described in the 
> mecab-ko page:
> https://bitbucket.org/eunjeon/mecab-ko
> Ignoring whitespaces is also more inlined with the official MeCab library 
> which attach the whitespaces to the term that follows.
> I also added a decompounder filter that expand the compounds and inflects 
> defined in the dictionary and a part of speech filter similar to the Japanese
> that removes the morpheme that are not useful for relevance (suffix, prefix, 
> interjection, ...). These filters don't play well with the tokenizer if it 
> can 
> output multiple paths (nBest output for instance) so for simplicity I removed 
> this ability and the Korean tokenizer only outputs the best path.
> I compared the result with mecab-ko to confirm that the analyzer is working 
> and ran the relevancy test that is defined in HantecRel.java included
> in the patch (written by Robert for another Korean analyzer). Here are the 
> results:
> ||Analyzer||Index Time||Index Size||MAP(CLASSIC)||MAP(BM25)||MAP(GL2)||
> |Standard|35s|131MB|.007|.1044|.1053|
> |CJK|36s|164MB|.1418|.1924|.1916|
> |Korean|212s|90MB|.1628|.2094|.2078|
> I find the results very promising so I plan to continue to work on this 
> project. I started to extract the part of the code that could be shared with 
> the
> Kuromoji module but I wanted to share the status and this POC first to 
> confirm that this approach is viable. The advantages of using the same model 
> than
> the Japanese analyzer are multiple: we don't have a Korean analyzer at the 
> moment ;), the resulting dictionary is small compared to other libraries that
> use the mecab-ko-dic (the FST takes only 5.4MB) and the Tokenizer prunes the 
> lattice on the fly to select the best path efficiently.
> The dictionary can be built directly from the godori module with the 
> following command:
> ant regenerate (you need to create the resource directory (mkdir 
> lucene/analysis/godori/src/resources/org/apache/lucene/analysis/ko/dict) 
> first since the dictionary is not included in the patch).
> I've also added some minimal tests in the module to play with the analysis.



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

-
To unsubscribe, 

[jira] [Comment Edited] (SOLR-11971) CVE-2018-1308: XXE attack through DIH's dataConfig request parameter

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-11971 at 4/10/18 11:28 AM:


Hi [~wunder],
as written in my announcement mail, there is no way to disable the "dataConfig" 
 parameter in running installations, unless you completely disable DIH. So your 
options are:
- disable DIH completely (yeah, not so nice)
- update to later version
- instruct your reverse proxy to remove "dataConfig" parameter before passing 
to Solr. I have seen configs for nginx doing similar things with the 
"stream.body" parameters.
- run Solr only on localhost
- install a firewall (that's a joke, you should have done this already)



was (Author: thetaphi):
Hi [~wunder],
as written in my announcement mail, there is no way to disable the "dataConfig" 
 parameter in running installations, unless you completely disable DIH. So your 
options are:
- disable DIH completely (yeah, not so nice)
- update to later version
- instruct your reverse proxy to remove "dataConfig" parameter before passing 
to Solr. I have seen configs for nginx doing similar things with the 
"stream.body" parameters.
- run Solr only on localhost
- install a firewall


> CVE-2018-1308: XXE attack through DIH's dataConfig request parameter
> 
>
> Key: SOLR-11971
> URL: https://issues.apache.org/jira/browse/SOLR-11971
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 6.6.3, 7.3, master (8.0)
>
> Attachments: ApacheSolrDIH-XXE.pdf, SOLR-11971.patch
>
>
> We got a security report about an XXE attack when using the 
> {{=}} of Solr's DataImportHandler. See the attached PDF 
> file with full details (I converted it to PDF, originally it was a DOC file).



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

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12207:
--

+1.

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-11251) Ref Guide: Add docs on JSON facet module

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11251:


Commit eb394a328ae2d7bcf2d1d994e39da35f327b7b60 in lucene-solr's branch 
refs/heads/branch_7x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb394a3 ]

SOLR-11251: documenting debug=timing hint for JSON Facet API.


> Ref Guide: Add docs on JSON facet module
> 
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON 
> facets, but it never made its way into the published guides. During the 
> conversion of the Ref Guide from Confluence, I made sure the page was 
> exported and converted to {{.adoc}} format.
> The doc was never updated after any of the changes that have been made to 
> JSON facet functionality since it was originally written, so it's possibly 
> inaccurate or just out of date. Someone could take a crack at finishing the 
> conversion cleanup and updating it with latest information so someday it can 
> be part of the published Guide.



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

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

[jira] [Created] (SOLR-12209) add Paging Streaming Expression

[mosh (JIRA)]

mosh created SOLR-12209:
---

 Summary: add Paging Streaming Expression
 Key: SOLR-12209
 URL: https://issues.apache.org/jira/browse/SOLR-12209
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: mosh


Currently the closest streaming expression that allows some sort of pagination 
is top.
I propose we add a new streaming expression, which is based on the RankedStream 
class to add offset to the stream. currently it can only be done in code by 
reading the stream until the desired offset is reached.

The new expression will be used as such:
{{paging(rows=3, search(collection1, q="*:*", qt="/export", 
fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
start=100)}}

{{this will offset the returned stream by 100 documents}}

 

[~joel.bernstein] what to you think?



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12207:
-

[^SOLR-12207.patch] is going to be a bug fix. Committing today.  

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12207:

Attachment: SOLR-12207.patch

> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-8245:
--

Hello, 
I'm afraid it may hurt precommit like 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/ 


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

Re: Potential BadApple report this week

[Erick Erickson]

Shalin:

Got it, thanks

On Tue, Apr 10, 2018 at 2:26 AM, Shalin Shekhar Mangar
 wrote:
> Hi Erick,
>
> You can go ahead and mark TestTriggerIntegration as BadApple. I don't think
> anyone is working on it. I was working on TriggerIntegrationTest which is a
> different test.
>
> On Mon, Apr 9, 2018 at 10:02 PM, Erick Erickson 
> wrote:
>>
>> OK, this is the first week I have Hoss' report from two weeks ago so
>> the list is rather lengthy.
>>
>>
>> I believe this test is being actively worked on, so no BadApple for it
>>
>> org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue
>>
>> ***Tests I'll BadApple on Thursday.
>>
>> These are tests that failed in the last week and _also_ are failures
>> in Hoss' report from two weeks ago, so nobody has addressed them in
>> that time-frame.
>>
>> PLEASE LET ME KNOW BEFORE THURSDAY WHICH OF THESE SHOULD NOT BE BADAPPLEd
>>
>>org.apache.lucene.index.TestIndexSorting.testRandom3
>>org.apache.solr.TestDistributedSearch.test
>>
>> org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions
>>org.apache.solr.cloud.AddReplicaTest.test
>>org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1
>>org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test
>>
>> org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent
>>org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate
>>org.apache.solr.cloud.CreateRoutedAliasTest.testV1
>>org.apache.solr.cloud.CreateRoutedAliasTest.testV2
>>org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing
>>
>> org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest
>>
>> org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState
>>org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest
>>
>> org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete
>>
>> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections
>>org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger
>>
>> org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState
>>
>> org.apache.solr.common.cloud.TestCollectionStateWatchers.testDeletionsTriggerWatches
>>
>> org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication
>>
>> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl
>>
>> org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
>>org.apache.solr.handler.TestReplicationHandler.doTestStressReplication
>>org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory
>>
>> org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.test
>>
>>
>> ***Tests currently BadApple-d
>>
>> *AwaitsFix Annotations:
>>
>>
>> Lucene AwaitsFix
>> TestControlledRealTimeReopenThread.java
>>testCRTReopen()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-5737;)
>>
>> TestICUNormalizer2CharFilter.java
>>testRandomStrings()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-5595;)
>>
>> TestMoreLikeThis.java
>>testMultiFieldShouldReturnPerFieldBooleanQuery()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-7161;)
>>
>> UIMABaseAnalyzerTest.java
>>testRandomStrings()
>>@Test @AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>>
>> UIMABaseAnalyzerTest.java
>>testRandomStringsWithConfigurationParameters()
>>@Test @AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>>
>> UIMATypeAwareAnalyzerTest.java
>>testRandomStrings()
>>@Test @AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>>
>>
>> Solr AwaitsFix
>> ReplaceNodeNoTargetTest.java
>>ReplaceNodeNoTargetTest suite
>>@LuceneTestCase.AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/SOLR-11067;)
>>
>> TestCollapseQParserPlugin.java
>>testStringCollapse()
>>@AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-11974;)
>>
>> TestImpersonationWithHadoopAuth.java
>>testForwarding()
>>@AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/HADOOP-9893;)
>>
>> TestLTRReRankingPipeline.java
>>testDifferentTopN()
>>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/SOLR-11134;)
>>
>> TestMinMaxOnMultiValuedField.java
>>testDoubleFieldCache()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-6709;)
>>
>> TestMinMaxOnMultiValuedField.java
>>testFloatFieldCache()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-6709;)
>>
>> TestMinMaxOnMultiValuedField.java
>>testIntFieldCache()
>>@AwaitsFix(bugUrl =
>> 

[jira] [Updated] (SOLR-12158) Allow the monteCarlo Stream Evaluator to support variables

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12158:
--
Attachment: SOLR-12158.patch

> Allow the monteCarlo Stream Evaluator to support variables 
> ---
>
> Key: SOLR-12158
> URL: https://issues.apache.org/jira/browse/SOLR-12158
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12158.patch
>
>
> This ticket will allow the *monteCarlo* function to assign variables on each 
> iteration. This will allow for much more readable and flexible Monte Carlo 
> simulations. Sample syntax:
> {code:java}
> let(a=normalDistribution(10, 5),
> b=normalDistribution(20, 3),
> c=monteCarlo(d=sample(a),
>  e=sample(b),
>  add(d, e),
>  5)){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-11251) Ref Guide: Add docs on JSON facet module

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11251:


Commit ce061a5198910261508be67fd47536989f5bb8bc in lucene-solr's branch 
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ce061a5 ]

SOLR-11251: documenting debug=timing hint for JSON Facet API.


> Ref Guide: Add docs on JSON facet module
> 
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON 
> facets, but it never made its way into the published guides. During the 
> conversion of the Ref Guide from Confluence, I made sure the page was 
> exported and converted to {{.adoc}} format.
> The doc was never updated after any of the changes that have been made to 
> JSON facet functionality since it was originally written, so it's possibly 
> inaccurate or just out of date. Someone could take a crack at finishing the 
> conversion cleanup and updating it with latest information so someday it can 
> be part of the published Guide.



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

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

[jira] [Updated] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-12187:

Attachment: SOLR-12187.patch

> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



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

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

[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 551 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 35299 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.25s), 6 error(s).

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:633: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:117: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/build.xml:119: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2264:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2466:
 Check for forbidden API calls failed, see log.

Total time: 95 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Comment Edited] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on LUCENE-8245 at 4/10/18 1:42 PM:
---

Hello, 
I'm afraid it may hurt precommit like 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/ 
{quote}
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
{quote}



was (Author: mkhludnev):
Hello, 
I'm afraid it may hurt precommit like 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/ 


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[JENKINS-MAVEN] Lucene-Solr-Maven-master #2232: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2232/

No tests ran.

Build Log:
[...truncated 31651 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:679: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 13 minutes 16 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (SOLR-11971) CVE-2018-1308: XXE attack through DIH's dataConfig request parameter

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-11971:
-

Sorry, figured it out after I posted that.

 

Does the default config enable the dataimporthandler? We only have it enabled 
on the very old clusters (Solr 3). This is a fine excuse for shutting them down.

> CVE-2018-1308: XXE attack through DIH's dataConfig request parameter
> 
>
> Key: SOLR-11971
> URL: https://issues.apache.org/jira/browse/SOLR-11971
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 6.6.3, 7.3, master (8.0)
>
> Attachments: ApacheSolrDIH-XXE.pdf, SOLR-11971.patch
>
>
> We got a security report about an XXE attack when using the 
> {{=}} of Solr's DataImportHandler. See the attached PDF 
> file with full details (I converted it to PDF, originally it was a DOC file).



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

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7262 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7262/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180410163438748, index.20180410163439057, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180410163438748, 
index.20180410163439057, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([56198242E8539A81:8DB28284ED7BF332]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:966)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:937)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:913)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12209) add Paging Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-12209:
---

I'm wondering if two separate functions: *skip* and *limit* might make sense?
{code:java}
limit(skip(search(...), 3), 50){code}
 

> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8245:
-

Well, I have a fix committed for case2.  But the fix only narrowly applies to 
that failure, apparently.  The full fix requires new math: I need to be able to 
determine, somehow, if the surface path of a plane which connects two points 
stays everywhere within MINIMUM_RESOLUTION of another plane.  I'll have to 
think that through but there's no more time today.

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

Re: [1/2] lucene-solr:master: LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.

[Adrien Grand]

Hey Karl,

The calls to Math.toDegrees seem to have made precommit angry.

Le mar. 10 avr. 2018 à 12:57,  a écrit :

> Repository: lucene-solr
> Updated Branches:
>   refs/heads/master d45211d53 -> b65229c90
>
>
> LUCENE-8245: Add more tests that demonstrate problems with
> GeoComplexPolygon.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/661fdf3a
> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/661fdf3a
> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/661fdf3a
>
> Branch: refs/heads/master
> Commit: 661fdf3a43e6d7a8b8b28254f69387209bafcd75
> Parents: 1cd8597
> Author: Karl Wright 
> Authored: Tue Apr 10 06:57:13 2018 -0400
> Committer: Karl Wright 
> Committed: Tue Apr 10 06:57:13 2018 -0400
>
> --
>  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  57 +++-
>  .../geom/RandomGeo3dShapeGenerator.java |   2 +-
>  .../spatial3d/geom/RandomGeoPolygonTest.java| 141 +++
>  3 files changed, 198 insertions(+), 2 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/661fdf3a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> --
> diff --git
> a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> index ee2217d..46750d4 100755
> ---
> a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> +++
> b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> @@ -21,12 +21,14 @@ import java.util.List;
>  import java.util.BitSet;
>  import java.util.Collections;
>
> +import org.apache.lucene.util.LuceneTestCase;
> +
>  import org.junit.Test;
>  import static org.junit.Assert.assertEquals;
>  import static org.junit.Assert.assertFalse;
>  import static org.junit.Assert.assertTrue;
>
> -public class GeoPolygonTest {
> +public class GeoPolygonTest extends LuceneTestCase {
>
>@Test
>public void testPolygonPointFiltering() {
> @@ -1518,5 +1520,58 @@ shape:
>  final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(12.282452091883385),
> Geo3DUtil.fromDegrees(-1.91633079336513E-11));
>  assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
>}
> +
> +  @Test
> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
> +  public void testLUCENE8245_case2() {
> +//POLYGON((5.512285089810178 -26.833721534785912,12.13983320542565
> -16.085163683089583,4.868755337835201 -9.167423203860656,0.0
> -5.261747514529465,-15.696549288211289
> -21.362181191487718,5.512285089810178 -26.833721534785912))
> +final List points = new ArrayList<>();
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-26.833721534785912),
> Geo3DUtil.fromDegrees(5.512285089810178)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-16.085163683089583),
> Geo3DUtil.fromDegrees(12.13983320542565)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-9.167423203860656),
> Geo3DUtil.fromDegrees(4.868755337835201)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-5.261747514529465), Geo3DUtil.fromDegrees(0.0)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-21.362181191487718),
> Geo3DUtil.fromDegrees(-15.696549288211289)));
> +final GeoPolygonFactory.PolygonDescription description = new
> GeoPolygonFactory.PolygonDescription(points);
> +final GeoPolygon polygon =
> GeoPolygonFactory.makeGeoPolygon(PlanetModel.SPHERE, description);
> +final GeoPolygon largePolygon =
> GeoPolygonFactory.makeLargeGeoPolygon(PlanetModel.SPHERE,
> Collections.singletonList(description));
> +//POINT(-6.994273817216168E-11 -1.6915596606526662E-292)
> +final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-1.6915596606526662E-292),
> Geo3DUtil.fromDegrees(-6.994273817216168E-11));
> +assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
> +  }
> +
> +  @Test
> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
> +  public void testLUCENE8245_case3() {
> +//POLYGON((144.76249846857021 8.828705232593283,166.00162989841027
> -8.5E-322,157.03429484830787 64.92565566857392,108.64696979831984
> 39.10241638996957,102.54234512410089 20.471658760034586,144.76249846857021
> 8.828705232593283))
> +final List points = new ArrayList<>();
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(8.828705232593283),
> 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+5) - Build # 1686 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1686/
Java: 64bit/jdk-11-ea+5 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 1744 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J0-20180410_124614_15513935629089448698387.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J2-20180410_124614_15516382972640814637937.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 56 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J1-20180410_124614_1554959568969402384072.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 298 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20180410_125314_11416462754829122027670.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20180410_125314_1206139906454236148981.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20180410_125314_11413188431785871423440.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 1068 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20180410_125440_8432075976365707990394.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20180410_125440_84010357564838546165473.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20180410_125440_84516912221154623117630.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 253 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J0-20180410_125621_1135443378818747601414.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 5 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J2-20180410_125621_11313899141105397098227.syserr
   [junit4] >>> JVM J2 emitted unexpected 

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 16e5ab161cc97a46c4dd115c409e8ed4ddf3b40f in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=16e5ab1 ]

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope 
planes.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 99e5a411861fdd9a0af2eda4c09fa83b49e80d11 in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=99e5a41 ]

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope 
planes.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-12187:
-

Patch for this ticket
 * Each replica will register a CollectionStateWatcher to unload itself when it 
is removed from clusterstate
 * Reverse changes made by SOLR-12176, changes of that issue is no longer 
needed since zombie leader cannot exist with this patch
 * Test
 * Refactoring ZkController.register() for better handling race-condition cases.

> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



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

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

[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

[JIRA]

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

Jan Høydahl commented on SOLR-12194:


Or is there a better way we could support any auth scheme on a per-request 
basis through being able to e.g. {{request.setCredentialsProvider(provider)}} 
where Solr will check the request for a provider and use that instead of the 
one configured through the client builder? Have not checked the APIs in detail 
but is the principle worth discussing?

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
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-12160) Document Time Routed Aliases separate from API

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-12160:

Attachment: SOLR-12160.patch

> Document Time Routed Aliases separate from API
> --
>
> Key: SOLR-12160
> URL: https://issues.apache.org/jira/browse/SOLR-12160
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12160.patch, SOLR-12160.patch, 
> time-routed-aliases.adoc
>
>
> Time Routed Aliases ought to have some documentation that is apart from the 
> API details which are already documented (thanks to Gus for that part).



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 14b313f42bbc061704232eda0d0c3ff1405fe9e3 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=14b313f ]

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope 
planes.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (LUCENE-8246) Allow to customize the number of deletes a merge claims

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8246:


+1

> Allow to customize the number of deletes a merge claims
> ---
>
> Key: LUCENE-8246
> URL: https://issues.apache.org/jira/browse/LUCENE-8246
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8246.patch
>
>
> With the introduction of soft deletes no every merge claims all documents 
> that are marked as deleted in the segment readers. MergePolicies still need 
> to do accurate accounting in order to select segments for merging and need to 
> decide if segments are merged. This chance allows the merge policy to 
> customize the number of deletes a merge of a segment claims.



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

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 539 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/539/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImportInnerEntity

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001

at 
__randomizedtesting.SeedInfo.seed([59CFAF3F0ADDF322:A8B8038AABBE80B5]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd$SolrInstance.tearDown(TestSolrEntityProcessorEndToEnd.java:360)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.tearDown(TestSolrEntityProcessorEndToEnd.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Updated] (SOLR-12181) Add trigger based on document count

[Andrzej Bialecki (JIRA)]

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

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

> Add trigger based on document count
> ---
>
> Key: SOLR-12181
> URL: https://issues.apache.org/jira/browse/SOLR-12181
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12181.patch
>
>
> This may turn out to be as simple as using a {{MetricTrigger}} but it's 
> likely this will require some specialization, and we may want to add this 
> type of trigger anyway for convenience.
> The two control actions associated with this trigger will be SPLITSHARD and 
> (yet nonexistent) MERGESHARD.



--
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-12210) Perfomance degradation at Hghi Load

[ROMAN NAZARENKO (JIRA)]

ROMAN NAZARENKO created SOLR-12210:
--

 Summary: Perfomance degradation at Hghi Load
 Key: SOLR-12210
 URL: https://issues.apache.org/jira/browse/SOLR-12210
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Hadoop Integration
Affects Versions: 7.2
Reporter: ROMAN NAZARENKO


When hdfsDataFactory is used and the incoming data stream is large, the rate of 
indexation is degraded. This is not a problem when using a local file system. I 
think the problem is in cleaning hdfsBlockCache. Because the degradation of the 
indexing rate occurs precisely when this cache reaches its maximum value. The 
basis for hdfsBlockCache is caffeine cache, but it is configured to clean only 
when the maximum size is reached. At the same time, nothing prevents using 
timeEviction, I suggest testing the indexing speed using this type of cache 
cleaning.



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit b873d1fb3422206ff7adf756791258333f1bf9f0 in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b873d1f ]

LUCENE-8245: Fix precommit.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 61c37551aca28341acef176d9dc088b37c84d307 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=61c3755 ]

LUCENE-8245: Fix precommit.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on LUCENE-8245:


I'm still seeing precommit errors. Am about to push out a fix for them.

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Commented] (SOLR-12181) Add trigger based on document count

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12181:
--

This patch adds {{IndexSizeTrigger}}, tests and supporting changes, among 
others:
* a barebones {{SplitShardSuggester}} to handle SPLITSHARD requests
* stubs to handle the future MERGESHARDS (SOLR-9407)
* extensions to the simulation framework to support index updates, tracking 
index size and document count metrics.

The trigger supports mixed lower and upper bounds defined in terms of index 
size (using the {{INDEX.sizeInBytes}} metric) and document counts (using the 
{{SEARCHER.searcher.numDocs}} metric), as well as defining custom operations to 
perform when bounds are exceeded, both lower and upper ones:

* aboveBytes - upper bound defined using index size in bytes
* aboveDocs - upper bound defined using number of docs
* belowBytes - lower bound defined using index size in bytes
* belowDocs - lower bound defined using number of docs
* aboveOp - operation to perform when any upper bound is exceeded. The default 
operation is SPLITSHARD
* belowOp - operation to perform when any lower bound is exceeded. The default 
operation is MERGESHARDS
* collections - comma-separated list of collections, or empty / none to 
consider all collections

> Add trigger based on document count
> ---
>
> Key: SOLR-12181
> URL: https://issues.apache.org/jira/browse/SOLR-12181
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12181.patch
>
>
> This may turn out to be as simple as using a {{MetricTrigger}} but it's 
> likely this will require some specialization, and we may want to add this 
> type of trigger anyway for convenience.
> The two control actions associated with this trigger will be SPLITSHARD and 
> (yet nonexistent) MERGESHARD.



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 19feef73bf17796cad27215602a8f5cdad5266f1 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=19feef7 ]

LUCENE-8245: Fix precommit.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[jira] [Updated] (SOLR-12205) SOLR-7887 broke javadoc:jar in maven

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12205:
-
Affects Version/s: (was: 7.3)
   7.4

> SOLR-7887 broke javadoc:jar in maven
> 
>
> Key: SOLR-12205
> URL: https://issues.apache.org/jira/browse/SOLR-12205
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 7.4, master (8.0)
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Major
>  Labels: maven
> Fix For: 7.4
>
>
> Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the 
> javadoc command line.  That is not a javadoc option, so mvn javadoc:jar fails 
> both on master and branch_7x.
> The following fix works for me:
> {code:java}
> diff --git a/dev-tools/maven/pom.xml.template 
> b/dev-tools/maven/pom.xml.template
> index 4e21ca0e13..50299a3cda 100644
> --- a/dev-tools/maven/pom.xml.template
> +++ b/dev-tools/maven/pom.xml.template
> @@ -238,7 +238,6 @@
> true
> -Xdoclint:all
> -Xdoclint:-missing
> - -proc:none
> 
> 
> 
> {code}
> The ant build is fine, its just the maven build which is affected.



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

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

[jira] [Commented] (SOLR-12158) Allow the monteCarlo Stream Evaluator to support variables

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12158:


Commit 9ebe11f1d952b083ad5e60bc589efb6aa4148a48 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9ebe11f ]

SOLR-12158: Allow the monteCarlo Stream Evaluator to support variables


> Allow the monteCarlo Stream Evaluator to support variables 
> ---
>
> Key: SOLR-12158
> URL: https://issues.apache.org/jira/browse/SOLR-12158
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12158.patch
>
>
> This ticket will allow the *monteCarlo* function to assign variables on each 
> iteration. This will allow for much more readable and flexible Monte Carlo 
> simulations. Sample syntax:
> {code:java}
> let(a=normalDistribution(10, 5),
> b=normalDistribution(20, 3),
> c=monteCarlo(d=sample(a),
>  e=sample(b),
>  add(d, e),
>  5)){code}
>  
>  
>  



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit e90ab4bb8191644a19308c30a3e4752043d50985 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e90ab4b ]

LUCENE-8245: Fix precommit


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[GitHub] lucene-solr pull request #345: LUCENE-8229: Add Weight.matches() method

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/345#discussion_r180492694
  
--- Diff: 
lucene/core/src/java/org/apache/lucene/search/DisjunctionMatchesIterator.java 
---
@@ -0,0 +1,168 @@
+/*
+ * 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.search;
+
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Objects;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PostingsEnum;
+import org.apache.lucene.index.Term;
+import org.apache.lucene.index.Terms;
+import org.apache.lucene.index.TermsEnum;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.BytesRefIterator;
+import org.apache.lucene.util.PriorityQueue;
+
+/**
+ * A {@link MatchesIterator} that combines matches from a set of 
sub-iterators
+ *
+ * Matches are sorted by their start positions, and then by their end 
positions, so that
+ * prefixes sort first.  Matches may overlap, or be duplicated if they 
appear in more
+ * than one of the sub-iterators.
+ */
+final class DisjunctionMatchesIterator implements MatchesIterator {
+
+  /**
+   * Create a {@link DisjunctionMatchesIterator} over a list of terms
+   *
+   * Only terms that have at least one match in the given document will be 
included
+   */
+  static MatchesIterator fromTerms(LeafReaderContext context, int doc, 
String field, List terms) throws IOException {
+for (Term term : terms) {
+  if (Objects.equals(field, term.field()) == false) {
+throw new IllegalArgumentException("Tried to generate iterator 
from terms in multiple fields: expected [" + field + "] but got [" + 
term.field() + "]");
+  }
+}
+return fromTermsEnum(context, doc, field, asBytesRefIterator(terms));
+  }
+
+  private static BytesRefIterator asBytesRefIterator(List terms) {
+return new BytesRefIterator() {
+  int i = 0;
+  @Override
+  public BytesRef next() {
+if (i >= terms.size())
+  return null;
+return terms.get(i++).bytes();
+  }
+};
+  }
+
+  /**
+   * Create a {@link DisjunctionMatchesIterator} over a list of terms 
extracted from a {@link BytesRefIterator}
+   *
+   * Only terms that have at least one match in the given document will be 
included
+   */
+  static MatchesIterator fromTermsEnum(LeafReaderContext context, int doc, 
String field, BytesRefIterator terms) throws IOException {
+List mis = new ArrayList<>();
+Terms t = context.reader().terms(field);
+if (t == null)
+  return null;
+TermsEnum te = t.iterator();
+PostingsEnum reuse = null;
+for (BytesRef term = terms.next(); term != null; term = terms.next()) {
+  if (te.seekExact(term)) {
+PostingsEnum pe = te.postings(reuse, PostingsEnum.OFFSETS);
+if (pe.advance(doc) == doc) {
+  // TODO do we want to use the copied term here, or instead 
create a label that associates all of the TMIs with a single term?
+  mis.add(new TermMatchesIterator(BytesRef.deepCopyOf(term), pe));
+  reuse = null;
+}
+else {
+  reuse = pe;
+}
+  }
+}
+if (mis.size() == 0)
+  return null;
+if (mis.size() == 1)
+  return mis.get(0);
+return new DisjunctionMatchesIterator(mis);
+  }
+
+  static MatchesIterator fromSubIterators(List mis) 
throws IOException {
+if (mis.size() == 0)
+  return null;
+if (mis.size() == 1)
+  return mis.get(0);
+return new DisjunctionMatchesIterator(mis);
+  }
+
+  private final PriorityQueue queue;
+
+  private boolean started = false;
+
+  private DisjunctionMatchesIterator(List matches) throws 
IOException {
+queue = new 

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1687 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1687/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 35403 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.12s), 6 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build.xml:119: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2264: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2466: 
Check for forbidden API calls failed, see log.

Total time: 71 minutes 52 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[GitHub] lucene-solr pull request #345: LUCENE-8229: Add Weight.matches() method

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/345#discussion_r180494440
  
--- Diff: lucene/core/src/java/org/apache/lucene/search/Weight.java ---
@@ -69,6 +69,24 @@ protected Weight(Query query) {
*/
   public abstract void extractTerms(Set terms);
 
+  /**
+   * Returns {@link Matches} for a specific document, or {@code null} if 
the document
+   * does not match the parent query
+   *
+   * A query match that contains no position information (for example, a 
Point or
+   * DocValues query) will return {@link Matches#MATCH_WITH_NO_TERMS}
+   *
+   * @param context the reader's context to create the {@link Matches} for
+   * @param doc the document's id relative to the given context's 
reader
+   */
+  public Matches matches(LeafReaderContext context, int doc) throws 
IOException {
+Scorer scorer = scorer(context);
+if (scorer == null || scorer.iterator().advance(doc) != doc) {
--- End diff --

we might want to check the two-phase iterator instead if there is one so 
that `iterator().advance()` doesn't potentially visit millions of candidates 
before finding one that actually matches. See for instance 
ConstantScoreWeight.explain.


---

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

[jira] [Commented] (SOLR-12158) Allow the monteCarlo Stream Evaluator to support variables

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12158:


Commit b1ea9d9898aa060653c7c46ec0789efffa5d9047 in lucene-solr's branch 
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b1ea9d9 ]

SOLR-12158: Allow the monteCarlo Stream Evaluator to support variables


> Allow the monteCarlo Stream Evaluator to support variables 
> ---
>
> Key: SOLR-12158
> URL: https://issues.apache.org/jira/browse/SOLR-12158
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12158.patch
>
>
> This ticket will allow the *monteCarlo* function to assign variables on each 
> iteration. This will allow for much more readable and flexible Monte Carlo 
> simulations. Sample syntax:
> {code:java}
> let(a=normalDistribution(10, 5),
> b=normalDistribution(20, 3),
> c=monteCarlo(d=sample(a),
>  e=sample(b),
>  add(d, e),
>  5)){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 pull request #345: LUCENE-8229: Add Weight.matches() method

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/345#discussion_r180496635
  
--- Diff: 
lucene/join/src/java/org/apache/lucene/search/join/ToParentBlockJoinQuery.java 
---
@@ -151,6 +152,17 @@ public Explanation explain(LeafReaderContext context, 
int doc) throws IOExceptio
   }
   return Explanation.noMatch("Not a match");
 }
+
+@Override
+public Matches matches(LeafReaderContext context, int doc) throws 
IOException {
+  // The default implementation would delegate to the joinQuery's 
Weight, which
+  // matches on children.  We need to match on the parent instead
+  Scorer scorer = scorer(context);
+  if (scorer == null || scorer.iterator().advance(doc) != doc) {
+return null;
+  }
--- End diff --

let's check the two-phase iterator here as well if applicable?


---

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

[JENKINS-MAVEN] Lucene-Solr-Maven-7.x #179: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/179/

No tests ran.

Build Log:
[...truncated 31703 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:679: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 13 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+5) - Build # 21794 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21794/
Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 35339 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.12s), 6 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build.xml:119: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2264: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2466: 
Check for forbidden API calls failed, see log.

Total time: 73 minutes 39 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
58s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 53s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 42m 
29s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 46m  8s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12207 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12918375/SOLR-12207.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / b65229c |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_152 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/48/testReport/ |
| modules | C: solr solr/core U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/48/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12160) Document Time Routed Aliases separate from API

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-12160:
-

Patch with suggested edits. Goal mostly was to make it so someone skipping 
around in the docs and not reading linearly from start to end would be better 
able to consume the parts and also I decided to use the term "segment" to refer 
to the time interval represented by a collection in the TRA, which I thought 
added some clarity by relating things to "slices" of time without using the 
term "slice" which has meaning/usage in other contexts already.

> Document Time Routed Aliases separate from API
> --
>
> Key: SOLR-12160
> URL: https://issues.apache.org/jira/browse/SOLR-12160
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12160.patch, SOLR-12160.patch, 
> time-routed-aliases.adoc
>
>
> Time Routed Aliases ought to have some documentation that is apart from the 
> API details which are already documented (thanks to Gus for that part).



--
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-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12207:


Commit f8f1e23b8fe6c105a7c7f1c1e76a49af382a0dd4 in lucene-solr's branch 
refs/heads/branch_7x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f8f1e23 ]

SOLR-12207: rethowing AssertionError from jdk reflection bug


> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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-12203) Error in response for field containing date. Unexpected state.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-12203:
---

Please raise issues like this on the user's list first, when we determine that 
it's a code issue, then we usually raise a JIRA.

Did you change your schema at any point and _not_ rebuild your collection from 
scratch? Or if you upgraded did you use your old schema types or just use a 7x 
one? Because this kind of looks like you have some segments with one definition 
for a field and other segments with a different definition.



> Error in response for field containing date. Unexpected state.
> --
>
> Key: SOLR-12203
> URL: https://issues.apache.org/jira/browse/SOLR-12203
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 7.2.1, 7.3
>Reporter: Jeroen Steggink
>Priority: Minor
>
> I get the following error:
> {noformat}
> java.lang.AssertionError: Unexpected state. Field: 
> stored,indexed,tokenized,omitNorms,indexOptions=DOCSds_lastModified:2013-10-04T22:25:11Z
> at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
> at org.apache.solr.schema.PointField.write(PointField.java:198)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
> at 
> org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
> at 
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
> at 
> 

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 48325cf8ce8de647300409def9c0b18c116ea307 in lucene-solr's branch 
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=48325cf ]

LUCENE-8245: Fix precommit


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 38 - Failure

[Apache Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 76, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12207:


Commit 764dcc336b148700dbbb77d43183ef5ac889e320 in lucene-solr's branch 
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=764dcc3 ]

SOLR-12207: rethowing AssertionError from jdk reflection bug


> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
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/jdk1.8.0_162) - Build # 21795 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21795/
Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 35293 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.11s), 6 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build.xml:119: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2264: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2466: 
Check for forbidden API calls failed, see log.

Total time: 75 minutes 38 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

Re: [1/2] lucene-solr:master: LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.

[Karl Wright]

Should be resolved now.
Sorry for the noise!

Karl


On Tue, Apr 10, 2018 at 9:03 AM, Adrien Grand  wrote:

> Hey Karl,
>
> The calls to Math.toDegrees seem to have made precommit angry.
>
> Le mar. 10 avr. 2018 à 12:57,  a écrit :
>
>> Repository: lucene-solr
>> Updated Branches:
>>   refs/heads/master d45211d53 -> b65229c90
>>
>>
>> LUCENE-8245: Add more tests that demonstrate problems with
>> GeoComplexPolygon.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/
>> 661fdf3a
>> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/661fdf3a
>> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/661fdf3a
>>
>> Branch: refs/heads/master
>> Commit: 661fdf3a43e6d7a8b8b28254f69387209bafcd75
>> Parents: 1cd8597
>> Author: Karl Wright 
>> Authored: Tue Apr 10 06:57:13 2018 -0400
>> Committer: Karl Wright 
>> Committed: Tue Apr 10 06:57:13 2018 -0400
>>
>> --
>>  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  57 +++-
>>  .../geom/RandomGeo3dShapeGenerator.java |   2 +-
>>  .../spatial3d/geom/RandomGeoPolygonTest.java| 141
>> +++
>>  3 files changed, 198 insertions(+), 2 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/
>> 661fdf3a/lucene/spatial3d/src/test/org/apache/lucene/
>> spatial3d/geom/GeoPolygonTest.java
>> --
>> diff --git 
>> a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
>> b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/
>> geom/GeoPolygonTest.java
>> index ee2217d..46750d4 100755
>> --- a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/
>> geom/GeoPolygonTest.java
>> +++ b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/
>> geom/GeoPolygonTest.java
>> @@ -21,12 +21,14 @@ import java.util.List;
>>  import java.util.BitSet;
>>  import java.util.Collections;
>>
>> +import org.apache.lucene.util.LuceneTestCase;
>> +
>>  import org.junit.Test;
>>  import static org.junit.Assert.assertEquals;
>>  import static org.junit.Assert.assertFalse;
>>  import static org.junit.Assert.assertTrue;
>>
>> -public class GeoPolygonTest {
>> +public class GeoPolygonTest extends LuceneTestCase {
>>
>>@Test
>>public void testPolygonPointFiltering() {
>> @@ -1518,5 +1520,58 @@ shape:
>>  final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(12.282452091883385), Geo3DUtil.fromDegrees(-1.
>> 91633079336513E-11));
>>  assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
>>}
>> +
>> +  @Test
>> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
>> +  public void testLUCENE8245_case2() {
>> +//POLYGON((5.512285089810178 -26.833721534785912,12.13983320542565
>> -16.085163683089583,4.868755337835201 -9.167423203860656,0.0
>> -5.261747514529465,-15.696549288211289 -21.362181191487718,5.512285089810178
>> -26.833721534785912))
>> +final List points = new ArrayList<>();
>> +points.add(new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-26.833721534785912), Geo3DUtil.fromDegrees(5.
>> 512285089810178)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-16.085163683089583), Geo3DUtil.fromDegrees(12.
>> 13983320542565)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE, 
>> Geo3DUtil.fromDegrees(-9.167423203860656),
>> Geo3DUtil.fromDegrees(4.868755337835201)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE, 
>> Geo3DUtil.fromDegrees(-5.261747514529465),
>> Geo3DUtil.fromDegrees(0.0)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-21.362181191487718), Geo3DUtil.fromDegrees(-15.
>> 696549288211289)));
>> +final GeoPolygonFactory.PolygonDescription description = new
>> GeoPolygonFactory.PolygonDescription(points);
>> +final GeoPolygon polygon = GeoPolygonFactory.
>> makeGeoPolygon(PlanetModel.SPHERE, description);
>> +final GeoPolygon largePolygon = GeoPolygonFactory.
>> makeLargeGeoPolygon(PlanetModel.SPHERE, Collections.singletonList(
>> description));
>> +//POINT(-6.994273817216168E-11 -1.6915596606526662E-292)
>> +final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-1.6915596606526662E-292),
>> Geo3DUtil.fromDegrees(-6.994273817216168E-11));
>> +assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
>> +  }
>> +
>> +  @Test
>> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
>> +  public void testLUCENE8245_case3() {
>> +//POLYGON((144.76249846857021 8.828705232593283,166.00162989841027
>> -8.5E-322,157.03429484830787 64.92565566857392,108.64696979831984
>> 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4560 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4560/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 52795 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1026320364
 [ecj-lint] Compiling 20 source files to 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1026320364
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
 (at line 27)
 [ecj-lint] import static org.junit.Assert.assertEquals;
 [ecj-lint]   ^
 [ecj-lint] The import org.junit.Assert.assertEquals is never used
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
 (at line 28)
 [ecj-lint] import static org.junit.Assert.assertFalse;
 [ecj-lint]   
 [ecj-lint] The import org.junit.Assert.assertFalse is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
 (at line 29)
 [ecj-lint] import static org.junit.Assert.assertTrue;
 [ecj-lint]   ^^^
 [ecj-lint] The import org.junit.Assert.assertTrue is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/RandomGeoPolygonTest.java
 (at line 27)
 [ecj-lint] import static 
com.carrotsearch.randomizedtesting.RandomizedTest.randomDouble;
 [ecj-lint]   
^^
 [ecj-lint] The import 
com.carrotsearch.randomizedtesting.RandomizedTest.randomDouble is never used
 [ecj-lint] --
 [ecj-lint] 4 problems (4 errors)

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:633: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:208: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2264:
 The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2095:
 The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2128:
 Compile failed; see the compiler error output for details.

Total time: 105 minutes 23 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Commented] (SOLR-10783) Using Hadoop Credential Provider as SSL/TLS store password source

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10783:


Commit 750c7a98267941166bdca02a0b182476ed6ec2a5 in lucene-solr's branch 
refs/heads/branch_7x from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=750c7a9 ]

SOLR-10783: Add support for Hadoop Credential Provider as SSL/TLS store 
password source.


> Using Hadoop Credential Provider as SSL/TLS store password source
> -
>
> Key: SOLR-10783
> URL: https://issues.apache.org/jira/browse/SOLR-10783
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 7.0
>Reporter: Mano Kovacs
>Assignee: Mark Miller
>Priority: Major
> Attachments: SOLR-10783-fix.patch, SOLR-10783.patch, 
> SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch, 
> SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch
>
>
> As a second iteration of SOLR-10307, I propose support of hadoop credential 
> providers as source of SSL store passwords. 
> Motivation: When SOLR is used in hadoop environment, support of  HCP gives 
> better integration and unified method to pass sensitive credentials to SOLR.



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

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

unsubscribe

[Sarthak Sugandhi]

Hi team

I want to unsubscribe from mailing list.

Thanks,
Sarthak

[jira] [Commented] (SOLR-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-12036:


Attached draft SOLR-12036-adoc.patch with how the 
https://lucene.apache.org/solr/guide/7_3/streaming-expressions.html#streaming-requests-and-responses
 part of the Solr Reference Guide could be updated. Or would it be preferable 
to somehow mention both the {{StreamFactory}} base class as used in the current 
example and the {{DefaultStreamFactory}} convenience class?

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client 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-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12155:


Commit a39a6ce672406ff2b77110cdd7ed1d87aa3b1ac3 in lucene-solr's branch 
refs/heads/master from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a39a6ce ]

SOLR-12155: awake threads awaiting UIF. despite of exception.


> Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField() 
> 
>
> Key: SOLR-12155
> URL: https://issues.apache.org/jira/browse/SOLR-12155
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Kishor gandham
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, 
> SOLR-12155.patch, SOLR-12155.patch, stack.txt
>
>
> I am attaching a stack trace from our production Solr (7.2.1). Occasionally, 
> we are seeing SOLR becoming unresponsive. We are then forced to kill the JVM 
> and start solr again.
> We have a lot of facet queries and our index has approximately 15 million 
> documents. We have recently started using json.facet queries and some of the 
> facet fields use DocValues.



--
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-12036) factor out DefaultStreamFactory class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12036:


Commit bce3925cd8428841517af3cc29565a9e204e7cc7 in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bce3925 ]

SOLR-12036: Factor out DefaultStreamFactory solrj class.


> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client 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-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-12036:
---
Fix Version/s: master (8.0)
   7.4

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client 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-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12155:


Commit 6ac9a19aa89d3ff59408902700f0737bca14d3aa in lucene-solr's branch 
refs/heads/branch_7x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6ac9a19 ]

SOLR-12155: awake threads awaiting UIF. despite of exception.


> Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField() 
> 
>
> Key: SOLR-12155
> URL: https://issues.apache.org/jira/browse/SOLR-12155
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Kishor gandham
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, 
> SOLR-12155.patch, SOLR-12155.patch, stack.txt
>
>
> I am attaching a stack trace from our production Solr (7.2.1). Occasionally, 
> we are seeing SOLR becoming unresponsive. We are then forced to kill the JVM 
> and start solr again.
> We have a lot of facet queries and our index has approximately 15 million 
> documents. We have recently started using json.facet queries and some of the 
> facet fields use DocValues.



--
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-12036) factor out DefaultStreamFactory class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12036:


Commit e8f862ea444d1ccf4699cfcdcd67d30eec4cb1bc in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e8f862e ]

SOLR-12036: Factor out DefaultStreamFactory solrj class.


> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client 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-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-12036:
---
Attachment: SOLR-12036-adoc.patch

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



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

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

[jira] [Assigned] (SOLR-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-12036:
--

Assignee: Christine Poerschke

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client 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

Re: unsubscribe

[Cassandra Targett]

You need to send a mail to the unsubscribe address (
dev-unsubscr...@lucene.apache.org, see
https://lucene.apache.org/solr/community.html#mailing-lists-irc if you have
problems), from the address you used when you originally subscribed.

On Tue, Apr 10, 2018 at 2:50 PM, Sarthak Sugandhi <
sarthaksugand...@gmail.com> wrote:

> Hi team
>
> I want to unsubscribe from mailing list.
>
> Thanks,
> Sarthak
>

[jira] [Updated] (SOLR-12210) Perfomance degradation at High Load

[ROMAN NAZARENKO (JIRA)]

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

ROMAN NAZARENKO updated SOLR-12210:
---
Summary: Perfomance degradation at High Load  (was: Perfomance degradation 
at Hghi Load)

> Perfomance degradation at High Load
> ---
>
> Key: SOLR-12210
> URL: https://issues.apache.org/jira/browse/SOLR-12210
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration
>Affects Versions: 7.2
>Reporter: ROMAN NAZARENKO
>Priority: Minor
>
> When hdfsDataFactory is used and the incoming data stream is large, the rate 
> of indexation is degraded. This is not a problem when using a local file 
> system. I think the problem is in cleaning hdfsBlockCache. Because the 
> degradation of the indexing rate occurs precisely when this cache reaches its 
> maximum value. The basis for hdfsBlockCache is caffeine cache, but it is 
> configured to clean only when the maximum size is reached. At the same time, 
> nothing prevents using timeEviction, I suggest testing the indexing speed 
> using this type of cache cleaning.



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

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8245:
-

The more-rigorous way of properly discovering the above condition is sort of 
already present.  What's needed is to find the XYZBounds of the bit of arc 
between the intersection point and the end point of the arc, and make sure that 
it all fits within the envelope plane bounds.

Unfortunately, this is all rather expensive to compute -- mainly because of 
significant object creation being required.  Fortunately, it happens only in 
very specific cases so maybe it would be limited enough to not impact things 
too badly.  But no question it would need to happen every time an edge ends on 
an envelope plane, and the distance between the edge endpoint and the 
intersection point is greater than MINIMUM_RESOLUTION.

I'm going to take a break from this particular part of the problem to give 
myself a chance to think it through to be sure there isn't a better way.  I'm 
also going to analyze case3 to see what the issue is there -- tomorrow.

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



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

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