[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.4) - Build # 538 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/538/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
found:2[index.20180410102211883, index.20180410102213448, index.properties, 
replication.properties, snapshot_metadata]

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

[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&focusedCommentId=16431777#comment-16431777
 ] 

Ignacio Vera commented on LUCENE-8245:
--

I attached the patches:

case3: Contains three test cases.

1) The first cases seems to fail because we need to increase the envelope for 
asserting if we need to look for inner and outer crossings. The following seems 
to help:

 
{code:java}
final GeoPoint[] travelCrossings = travelPlane.findIntersections(planetModel, 
edge.plane, checkPointCutoffPlane, checkPointOtherCutoffPlane, edge.startPlane, 
edge.endPlane);
if (travelCrossings != null && travelCrossings.length == 0) {
  final GeoPoint[] testPointCrossings = 
testPointPlane.findIntersections(planetModel, edge.plane, testPointCutoffPlane, 
testPointOtherCutoffPlane, edge.startPlane, edge.endPlane);
  if (testPointCrossings != null && testPointCrossings.length == 0) {
// As a last resort, see if the edge endpoints are on either plane.  This 
is sometimes necessary because the
// intersection computation logic might not detect near-miss edges 
otherwise.
if (Math.abs(travelPlane.evaluate(edge.startPoint)) > 
Plane.MINIMUM_PLANE_OFFSET  &&
Math.abs(travelPlane.evaluate(edge.endPoint)) > 
Plane.MINIMUM_PLANE_OFFSET &&
Math.abs(testPointPlane.evaluate(edge.startPoint)) > 
Plane.MINIMUM_PLANE_OFFSET &&
Math.abs(testPointPlane.evaluate(edge.endPoint)) > 
Plane.MINIMUM_PLANE_OFFSET) {
  return true;
}
  }
}{code}
 

2)  We miss crossings but the end point or start point are actually on the 
plane. I have changed the way we count crossings and it seems to help:

 
{code:java}
if (testPointInnerCrossings != null && testPointInnerCrossings.length > 0) {
  for (final GeoPoint crossing : testPointInnerCrossings) {
//System.out.println("  Test point inner point "+crossing+"; 
edgeplane="+edge.plane.evaluate(crossing)+"; 
testPointInsidePlane="+testPointInsidePlane.evaluate(crossing)+"; 
edgestartplane="+edge.startPlane.evaluate(crossing)+"; 
edgeendplane="+edge.endPlane.evaluate(crossing));
countingHash.add(crossing);
  }
} else if (testPointOuterCrossings != null && testPointOuterCrossings.length > 
0) {
  if (testPointInsidePlane.evaluateIsZero(edge.endPoint) || 
testPointInsidePlane.evaluateIsZero(edge.startPoint)) {
countingHash.add(edge.endPoint);
  }
}{code}
 

I added the random test I am using to uncover all these cases. It still gets 
spurious errors but after the changes above they don't seem related with this 
case.

The last patch is my version of 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] [Updated] (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:all-tabpanel
 ]

Ignacio Vera updated LUCENE-8245:
-
Attachment: LUCENE-8245_case3.patch
LUCENE-8245_Polygon.patch
LUCENE-8245_Random.patch

> 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] [Reopened] (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:all-tabpanel
 ]

Ignacio Vera reopened LUCENE-8245:
--

I need to re-open again as I see still errors related with travel plane 
intersecting near a polygon point.

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



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

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

[jira] [Reopened] (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 reopened SOLR-12096:
-

Reopening. There are intermittent test failures: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/556/testReport/junit/org.apache.solr.response.transform/TestSubQueryTransformerDistrib/test/

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:34911/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:40235/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[https://127.0.0.1:34911/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:40235/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([FD79545AEA13C261:57B487A85DC017B1]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:308)
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.evaluat

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7261 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
found:2[index.20180410074335527, index.20180410074348185, index.properties, 
replication.properties, snapshot_metadata]

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

[JENKINS] Lucene-Solr-repro - Build # 472 - Still Unstable

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/34/consoleText

[repro] Revision: f0aed933a6674dadf7a563973c6d46e99901c5e6

[repro] Repro line:  ant test  -Dtestcase=MoveReplicaHDFSTest 
-Dtests.method=testFailedMove -Dtests.seed=B5BA6B803F8F7F6D 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=uk-UA -Dtests.timezone=America/Argentina/Tucuman 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
5e2a5a5b8c9ce2fe63cf2cd7eeb434e1a4969f22
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout f0aed933a6674dadf7a563973c6d46e99901c5e6

[...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]   MoveReplicaHDFSTest
[repro] ant compile-test

[...truncated 3293 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.MoveReplicaHDFSTest" -Dtests.showOutput=onerror  
-Dtests.seed=B5BA6B803F8F7F6D -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=uk-UA 
-Dtests.timezone=America/Argentina/Tucuman -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   1/5 failed: org.apache.solr.cloud.MoveReplicaHDFSTest
[repro] git checkout 5e2a5a5b8c9ce2fe63cf2cd7eeb434e1a4969f22

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

[JENKINS] Lucene-Solr-BadApples-master-Linux (32bit/jdk1.8.0_162) - Build # 20 - Unstable!

[Policeman Jenkins Server]

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

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (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&focusedCommentId=16431643#comment-16431643
 ] 

ASF subversion and git services commented on SOLR-10783:


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

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

Re: [jira] [Commented] (SOLR-9640) Support PKI authentication and SSL in standalone-mode master/slave auth with local security.json

[David Smiley]

bq. I’d argue that the scenario here is roughly the same as devs running
precommit locally; why should the automated checker behave differently?

+1 I agree to that sentiment; it ought to be the same.  BadApples are
handled in their dedicated jenkins job.

On Mon, Apr 9, 2018 at 8:57 PM Steve Rowe  wrote:

> The command that’s run is just “ant test” - see e.g. <
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-unit-solr_core.txt
> >.
>
> Sysprop tests.badapples is true by default these days (SOLR-12028), which
> is why this is happening.  (FYI I’m not particularly fond of this decision.)
>
> I’d argue that the scenario here is roughly the same as devs running
> precommit locally; why should the automated checker behave differently?
>
> --
> Steve
> www.lucidworks.com
>
> > On Apr 9, 2018, at 4:59 AM, Jan Høydahl  wrote:
> >
> > Hi,
> >
> > Looks like the auto Patch validation tests run @BadApple tests?
> >
> >> Failed junit tests  |  solr.cloud.TestLeaderElectionZkExpiry
> >
> > The test was bad-appled in March
> >
> >> @Test
> >> @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";)
> // 17-Mar-2018
> >> public void testLeaderElectionWithZkExpiry() throws Exception {
> > Is this on purpose?
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >> 9. apr. 2018 kl. 07:26 skrev Lucene/Solr QA (JIRA) :
> >>
> >>
> >>[
> https://issues.apache.org/jira/browse/SOLR-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430036#comment-16430036
> ]
> >>
> >> Lucene/Solr QA commented on SOLR-9640:
> >> --
> >>
> >> | (x) *{color:red}-1 overall{color}* |
> >> \\
> >> \\
> >> || Vote || Subsystem || Runtime || Comment ||
> >> || || || || {color:brown} Prechecks {color} ||
> >> | {color:green}+1{color} | {color:green} test4tests {color} |
> {color:green}  0m  0s{color} | {color:green} The patch appears to include 3
> new or modified test files. {color} |
> >> || || || || {color:brown} master Compile Tests {color} ||
> >> | {color:green}+1{color} | {color:green} compile {color} |
> {color:green}  1m 16s{color} | {color:green} master passed {color} |
> >> || || || || {color:brown} Patch Compile Tests {color} ||
> >> | {color:green}+1{color} | {color:green} compile {color} |
> {color:green}  1m 13s{color} | {color:green} the patch passed {color} |
> >> | {color:green}+1{color} | {color:green} javac {color} | {color:green}
> 1m 13s{color} | {color:green} the patch passed {color} |
> >> | {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
> {color:green}  1m  9s{color} | {color:green} the patch passed {color} |
> >> | {color:red}-1{color} | {color:red} Check forbidden APIs {color} |
> {color:red}  1m  6s{color} | {color:red} Check forbidden APIs
> check-forbidden-apis failed {color} |
> >> | {color:red}-1{color} | {color:red} Validate source patterns {color} |
> {color:red}  1m  6s{color} | {color:red} Check forbidden APIs
> check-forbidden-apis failed {color} |
> >> || || || || {color:brown} Other Tests {color} ||
> >> | {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m
> 32s{color} | {color:red} core in the patch failed. {color} |
> >> | {color:green}+1{color} | {color:green} unit {color} | {color:green}
> 0m 19s{color} | {color:green} test-framework in the patch passed. {color} |
> >> | {color:black}{color} | {color:black} {color} | {color:black} 56m
> 59s{color} | {color:black} {color} |
> >> \\
> >> \\
> >> || Reason || Tests ||
> >> | Failed junit tests | solr.cloud.TestLeaderElectionZkExpiry |
> >> \\
> >> \\
> >> || Subsystem || Report/Notes ||
> >> | JIRA Issue | SOLR-9640 |
> >> | JIRA Patch URL |
> https://issues.apache.org/jira/secure/attachment/12917997/SOLR-9640.patch
> |
> >> | Optional Tests |  compile  javac  unit  ratsources
> checkforbiddenapis  validatesourcepatterns  |
> >> | uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed
> Jun 8 21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
> >> | Build tool | ant |
> >> | Personality |
> /home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
> |
> >> | git revision | master / 3530397 |
> >> | ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
> >> | Default Java | 1.8.0_152 |
> >> | Check forbidden APIs |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-check-forbidden-apis-solr.txt
> |
> >> | Validate source patterns |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-check-forbidden-apis-solr.txt
> |
> >> | unit |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-unit-solr_core.txt
> |
> >> |  Test Results |
> https://builds.apache.org/job/PreCommit-SOLR-Build/44/testReport/ |
> >> | modules | C: solr solr/core solr/test-framework U: solr |
> >> | Console output |
> https://builds.apa

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

[Policeman Jenkins Server]

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

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (SOLR-12198) Stream Evaluators should not copy matrices needlessly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12198:


Commit 0f29510d6d23d13894714a9c8d400b3f4e814552 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=0f29510 ]

SOLR-12198: Fix precommit


> Stream Evaluators should not copy matrices needlessly
> -
>
> Key: SOLR-12198
> URL: https://issues.apache.org/jira/browse/SOLR-12198
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12198.patch
>
>
> Currently several of the Stream Evaluators that work with matrices are 
> creating multiple copies of the underlying multi-dimensional arrays. This can 
> lead to excessive memory usage. This ticket will change these implementations 
> so copies of the multi-dimensional arrays that back a matrix are only copied 
> when the *copyOf* function is used.



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

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

[jira] [Commented] (SOLR-12198) Stream Evaluators should not copy matrices needlessly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12198:


Commit 33c274babd4a60480a4c5cafc712babc97431739 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=33c274b ]

SOLR-12198: Stream Evaluators should not copy matrices needlessly


> Stream Evaluators should not copy matrices needlessly
> -
>
> Key: SOLR-12198
> URL: https://issues.apache.org/jira/browse/SOLR-12198
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12198.patch
>
>
> Currently several of the Stream Evaluators that work with matrices are 
> creating multiple copies of the underlying multi-dimensional arrays. This can 
> lead to excessive memory usage. This ticket will change these implementations 
> so copies of the multi-dimensional arrays that back a matrix are only copied 
> when the *copyOf* function is used.



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

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

[jira] [Commented] (SOLR-12198) Stream Evaluators should not copy matrices needlessly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12198:


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

SOLR-12198: Stream Evaluators should not copy matrices needlessly


> Stream Evaluators should not copy matrices needlessly
> -
>
> Key: SOLR-12198
> URL: https://issues.apache.org/jira/browse/SOLR-12198
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12198.patch
>
>
> Currently several of the Stream Evaluators that work with matrices are 
> creating multiple copies of the underlying multi-dimensional arrays. This can 
> lead to excessive memory usage. This ticket will change these implementations 
> so copies of the multi-dimensional arrays that back a matrix are only copied 
> when the *copyOf* function is used.



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

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

[jira] [Commented] (SOLR-12198) Stream Evaluators should not copy matrices needlessly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12198:


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

SOLR-12198: Fix precommit


> Stream Evaluators should not copy matrices needlessly
> -
>
> Key: SOLR-12198
> URL: https://issues.apache.org/jira/browse/SOLR-12198
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12198.patch
>
>
> Currently several of the Stream Evaluators that work with matrices are 
> creating multiple copies of the underlying multi-dimensional arrays. This can 
> lead to excessive memory usage. This ticket will change these implementations 
> so copies of the multi-dimensional arrays that back a matrix are only copied 
> when the *copyOf* function is used.



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

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

[JENKINS] Lucene-Solr-repro - Build # 471 - Unstable

[Apache Jenkins Server]

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

[...truncated 36 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2481/consoleText

[repro] Revision: f0aed933a6674dadf7a563973c6d46e99901c5e6

[repro] Repro line:  ant test  -Dtestcase=TestSubQueryTransformerDistrib 
-Dtests.method=test -Dtests.seed=2FD1598AA7C008EF -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=pl -Dtests.timezone=America/Campo_Grande 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
1cd859713bda498fe295b2774fa74640d669882b
[repro] git fetch
[repro] git checkout f0aed933a6674dadf7a563973c6d46e99901c5e6

[...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 3293 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestSubQueryTransformerDistrib" -Dtests.showOutput=onerror  
-Dtests.seed=2FD1598AA7C008EF -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=pl -Dtests.timezone=America/Campo_Grande -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

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

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

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1001 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1001/

No tests ran.

Build Log:
[...truncated 23731 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2190 links (1746 relative) to 3004 anchors in 243 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-S

Re: [jira] [Commented] (SOLR-9640) Support PKI authentication and SSL in standalone-mode master/slave auth with local security.json

[Steve Rowe]

The command that’s run is just “ant test” - see e.g. 
.

Sysprop tests.badapples is true by default these days (SOLR-12028), which is 
why this is happening.  (FYI I’m not particularly fond of this decision.)

I’d argue that the scenario here is roughly the same as devs running precommit 
locally; why should the automated checker behave differently?

--
Steve
www.lucidworks.com

> On Apr 9, 2018, at 4:59 AM, Jan Høydahl  wrote:
> 
> Hi,
> 
> Looks like the auto Patch validation tests run @BadApple tests?
> 
>> Failed junit tests  |  solr.cloud.TestLeaderElectionZkExpiry 
> 
> The test was bad-appled in March
> 
>> @Test
>> @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";) // 
>> 17-Mar-2018
>> public void testLeaderElectionWithZkExpiry() throws Exception {
> Is this on purpose?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
>> 9. apr. 2018 kl. 07:26 skrev Lucene/Solr QA (JIRA) :
>> 
>> 
>>[ 
>> https://issues.apache.org/jira/browse/SOLR-9640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430036#comment-16430036
>>  ] 
>> 
>> Lucene/Solr QA commented on SOLR-9640:
>> --
>> 
>> | (x) *{color:red}-1 overall{color}* |
>> \\
>> \\
>> || Vote || Subsystem || Runtime || Comment ||
>> || || || || {color:brown} Prechecks {color} ||
>> | {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  
>> 0m  0s{color} | {color:green} The patch appears to include 3 new or modified 
>> test files. {color} |
>> || || || || {color:brown} master Compile Tests {color} ||
>> | {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
>> 16s{color} | {color:green} master passed {color} |
>> || || || || {color:brown} Patch Compile Tests {color} ||
>> | {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
>> 13s{color} | {color:green} the patch passed {color} |
>> | {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
>> 13s{color} | {color:green} the patch passed {color} |
>> | {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
>> {color:green}  1m  9s{color} | {color:green} the patch passed {color} |
>> | {color:red}-1{color} | {color:red} Check forbidden APIs {color} | 
>> {color:red}  1m  6s{color} | {color:red} Check forbidden APIs 
>> check-forbidden-apis failed {color} |
>> | {color:red}-1{color} | {color:red} Validate source patterns {color} | 
>> {color:red}  1m  6s{color} | {color:red} Check forbidden APIs 
>> check-forbidden-apis failed {color} |
>> || || || || {color:brown} Other Tests {color} ||
>> | {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m 
>> 32s{color} | {color:red} core in the patch failed. {color} |
>> | {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
>> 19s{color} | {color:green} test-framework in the patch passed. {color} |
>> | {color:black}{color} | {color:black} {color} | {color:black} 56m 
>> 59s{color} | {color:black} {color} |
>> \\
>> \\
>> || Reason || Tests ||
>> | Failed junit tests | solr.cloud.TestLeaderElectionZkExpiry |
>> \\
>> \\
>> || Subsystem || Report/Notes ||
>> | JIRA Issue | SOLR-9640 |
>> | JIRA Patch URL | 
>> https://issues.apache.org/jira/secure/attachment/12917997/SOLR-9640.patch |
>> | Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
>> validatesourcepatterns  |
>> | uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
>> 21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
>> | Build tool | ant |
>> | Personality | 
>> /home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
>>  |
>> | git revision | master / 3530397 |
>> | ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
>> | Default Java | 1.8.0_152 |
>> | Check forbidden APIs | 
>> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-check-forbidden-apis-solr.txt
>>  |
>> | Validate source patterns | 
>> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-check-forbidden-apis-solr.txt
>>  |
>> | unit | 
>> https://builds.apache.org/job/PreCommit-SOLR-Build/44/artifact/out/patch-unit-solr_core.txt
>>  |
>> |  Test Results | 
>> https://builds.apache.org/job/PreCommit-SOLR-Build/44/testReport/ |
>> | modules | C: solr solr/core solr/test-framework U: solr |
>> | Console output | 
>> https://builds.apache.org/job/PreCommit-SOLR-Build/44/console |
>> | Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |
>> 
>> 
>> This message was automatically generated.
>> 
>> 
>> 
>>> Support PKI authentication and SSL in standalone-mode master/slave auth 
>>> with local security.json
>>> 
>>> 
>>>  

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1792 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ZkFailoverTest.testRestartZkWhenClusterDown

Error Message:
Collection not found: coll1

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: coll1
at 
__randomizedtesting.SeedInfo.seed([9A767CE8EF9C2780:F4E1FFA4967B8103]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:853)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at 
org.apache.solr.cloud.ZkFailoverTest.testRestartZkWhenClusterDown(ZkFailoverTest.java:50)
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(ThreadLeak

[jira] [Reopened] (SOLR-11731) LatLonPointSpatialField could be improved to return the lat/lon from docValues

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-11731:
---

Reproducing seed for a failure for a test introduced on this issue, from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4555/]:

{noformat}
Checking out Revision bd8fe72426b2a9df45050143e85481f523854239 
(refs/remotes/origin/master)
[...]
  [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSolr4Spatial2 
-Dtests.method=testLLPDecodeIsStableAndPrecise -Dtests.seed=4A0FE4EBBF28C333 
-Dtests.slow=true -Dtests.locale=sv-SE -Dtests.timezone=Asia/Novokuznetsk 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
  [junit4] FAILURE 0.02s J0 | TestSolr4Spatial2.testLLPDecodeIsStableAndPrecise 
{seed=[4A0FE4EBBF28C333:334C1482C273AE6C]} <<<
  [junit4]> Throwable #1: java.lang.AssertionError: deltaCm too high: 
1.3555223714857696
  [junit4]> at 
__randomizedtesting.SeedInfo.seed([4A0FE4EBBF28C333:334C1482C273AE6C]:0)
  [junit4]> at 
org.apache.solr.search.TestSolr4Spatial2.testLLPDecodeIsStableAndPrecise(TestSolr4Spatial2.java:167)
  [junit4]> at java.lang.Thread.run(Thread.java:748)
[...]
  [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{srptgeom=TestBloomFilteredLucenePostings(BloomFilteringPostingsFormat(Lucene50(blocksize=128))),
 bboxD_dynamic__xdl=Lucene50(blocksize=128), id=Lucene50(blocksize=128)}, 
docValues:{srptgeom=DocValuesFormat(name=Direct), 
bboxD_dynamic__maxX=DocValuesFormat(name=Direct), 
llp_N_dv_dvasst=DocValuesFormat(name=Lucene70), 
llp_1_dv_dvasst=DocValuesFormat(name=Memory), 
llp_1_dv_st=DocValuesFormat(name=Direct), 
llp_N_dv=DocValuesFormat(name=Lucene70), 
llp_N_dv_st=DocValuesFormat(name=Lucene70), 
bboxD_dynamic__minY=DocValuesFormat(name=Lucene70), 
llp_1_dv=DocValuesFormat(name=Direct), 
bboxD_dynamic__minX=DocValuesFormat(name=Memory), 
bboxD_dynamic__maxY=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=507, 
maxMBSortInHeap=5.869480725854461, 
sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@d8154da),
 locale=sv-SE, timezone=Asia/Novokuznetsk
  [junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
(64-bit)/cpus=3,threads=1,free=94769840,total=134217728
{noformat}

> LatLonPointSpatialField could be improved to return the lat/lon from docValues
> --
>
> Key: SOLR-11731
> URL: https://issues.apache.org/jira/browse/SOLR-11731
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-11731.patch, SOLR-11731.patch, SOLR-11731.patch
>
>  Time Spent: 4.5h
>  Remaining Estimate: 0h
>
> You can only return the lat & lon from a LatLonPointSpatialField if you set 
> stored=true.  But we could allow this (albeit at a small loss in precision) 
> if stored=false and docValues=true.



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

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

[jira] [Resolved] (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:all-tabpanel
 ]

Karl Wright resolved LUCENE-8245.
-
Resolution: Fixed

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



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

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

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

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on LUCENE-8245 at 4/10/18 12:21 AM:
--

bq. Not sure if it belongs on this issue, but this is a reproducing 
TestGeo3DPoint.testGeo3DRelations() failure, from 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4557/:

As of Karl's {{9bd6d13}} commit, this failure ^^ no longer reproduces.


was (Author: steve_rowe):
bq. Not sure if it belongs on this issue, but this is a reproducing 
TestGeo3DPoint.testGeo3DRelations() failure, from 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4557/:

As of Karl's {{1cd8597}} commit, this failure ^^ no longer reproduces.

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



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

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

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

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-8245:


bq. Not sure if it belongs on this issue, but this is a reproducing 
TestGeo3DPoint.testGeo3DRelations() failure, from 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4557/:

As of Karl's {{1cd8597}} commit, this failure ^^ no longer reproduces.

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



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

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 556 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/556/

1 tests failed.
FAILED:  org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test

Error Message:
mismatch: 'These guys develop stuff'!='These guys help customers' @ 
response/docs/[0]/depts/docs/[0]/text_t

Stack Trace:
java.lang.AssertionError: mismatch: 'These guys develop stuff'!='These guys 
help customers' @ response/docs/[0]/depts/docs/[0]/text_t
at 
__randomizedtesting.SeedInfo.seed([4831B4B32E31F316:C0658B6980CD9EEE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test(TestSubQueryTransformerDistrib.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 13191 lines...]
   [junit4] Suite: 
org.apache.solr.response.transform.TestSubQueryTransfor

[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&focusedCommentId=16431540#comment-16431540
 ] 

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

Commit 2ef5c946c3e19a49c712047f0825c26d5db09cf6 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=2ef5c94 ]

LUCENE-8245: Don't rely only on 'intersects' code to determine whether we 
should bother looking for crossings; also see if endpoints lie on travel 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
>
>
> 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&focusedCommentId=16431541#comment-16431541
 ] 

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

Commit 95435d4e738869a4dc46c5f47a59a7df44d0c593 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=95435d4 ]

LUCENE-8245: Don't rely only on 'intersects' code to determine whether we 
should bother looking for crossings; also see if endpoints lie on travel 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
>
>
> 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

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-8245:


Not sure if it belongs on this issue, but this is a reproducing 
{{TestGeo3DPoint.testGeo3DRelations()}} failure, from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4557/]:

{noformat}
Checking out Revision b82f5912a05ceffd28cf2a600c701e2fb387014d 
(refs/remotes/origin/master)
[...]
  [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
  [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
-Dtests.method=testGeo3DRelations -Dtests.seed=7BAAE36CC3CC7C16 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=shi-Tfng-MA 
-Dtests.timezone=America/Swift_Current -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
  [junit4] ERROR   0.67s J0 | TestGeo3DPoint.testGeo3DRelations <<<
  [junit4]> Throwable #1: java.lang.IllegalArgumentException: No off-plane 
intersection points were found; can't compute traversal
  [junit4]> at 
__randomizedtesting.SeedInfo.seed([7BAAE36CC3CC7C16:CBD59EF84C81D28A]:0)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.pickProximate(GeoComplexPolygon.java:1201)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.computeInsideOutside(GeoComplexPolygon.java:1181)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.matches(GeoComplexPolygon.java:1254)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Node.traverse(GeoComplexPolygon.java:664)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:760)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:746)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon.isWithin(GeoComplexPolygon.java:456)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.GeoBaseMembershipShape.isWithin(GeoBaseMembershipShape.java:36)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.BaseXYZSolid.isAreaInsideShape(BaseXYZSolid.java:130)
  [junit4]> at 
org.apache.lucene.spatial3d.geom.StandardXYZSolid.getRelationship(StandardXYZSolid.java:432)
  [junit4]> at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations(TestGeo3DPoint.java:311)
  [junit4]> at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  [junit4]> at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  [junit4]> at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  [junit4]> at 
java.base/java.lang.reflect.Method.invoke(Method.java:564)
  [junit4]> at java.base/java.lang.Thread.run(Thread.java:844)
[...]
  [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{id=BlockTreeOrds(blocksize=128)}, 
docValues:{id=DocValuesFormat(name=Lucene70), 
point=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=910, 
maxMBSortInHeap=5.851383459429137, 
sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@1f97fd1a),
 locale=shi-Tfng-MA, timezone=America/Swift_Current
  [junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 9 
(64-bit)/cpus=3,threads=1,free=30828472,total=54853632
{noformat}

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch
>
>
> 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 Atlassi

[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&focusedCommentId=16431537#comment-16431537
 ] 

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

Commit 9bd6d1305c8bbccf2f3a22079a523b483325e9eb 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=9bd6d13 ]

LUCENE-8245: Don't rely only on 'intersects' code to determine whether we 
should bother looking for crossings; also see if endpoints lie on travel 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
>
>
> 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-12206) SolrCLI can swallow all information about an exception from a request to Solr

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12206:
-

The patch above is against the 7.3 branch.  I have not yet checked whether it 
will apply cleanly to master.

> SolrCLI can swallow all information about an exception from a request to Solr
> -
>
> Key: SOLR-12206
> URL: https://issues.apache.org/jira/browse/SOLR-12206
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
>
> User got an NPE when trying to create a core, no useful information:
> {code}
> $ /usr/local/solr/bin/solr create -V -c new_core
> WARNING: Using _default configset with data driven schema functionality.
> NOT RECOMMENDED for production use.
>  To turn off: bin/solr config -c new_core -p 8983 -property
> update.autoCreateFields -value false
> Exception in thread "main" java.lang.NullPointerException
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:731)
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:642)
>   at org.apache.solr.util.SolrCLI$CreateTool.runImpl(SolrCLI.java:1773)
>   at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:176)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:282)
> {code}
> Looking at the code, this happened because SolrCLI got a 
> ClientProtocolException in its call to HttpClient, but that exception did NOT 
> have a message string attached, so when the code in the catch block tried to 
> look at the message, it threw NPE.



--
This message was sent by Atlassian 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-12206) SolrCLI can swallow all information about an exception from a request to Solr

[Shawn Heisey (JIRA)]

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

Shawn Heisey edited comment on SOLR-12206 at 4/10/18 12:00 AM:
---

The user in this situation had enabled SSL on their Solr instance.  My best 
guess about what happened is that HttpClient was unable to validate the 
certificate sent by the server.

 


was (Author: elyograg):
The user in this situation had enabled SSL on their Solr instance.  My best 
guess about what happened is that SolrCLI was unable to validate the 
certificate sent by the server.

 

> SolrCLI can swallow all information about an exception from a request to Solr
> -
>
> Key: SOLR-12206
> URL: https://issues.apache.org/jira/browse/SOLR-12206
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
>
> User got an NPE when trying to create a core, no useful information:
> {code}
> $ /usr/local/solr/bin/solr create -V -c new_core
> WARNING: Using _default configset with data driven schema functionality.
> NOT RECOMMENDED for production use.
>  To turn off: bin/solr config -c new_core -p 8983 -property
> update.autoCreateFields -value false
> Exception in thread "main" java.lang.NullPointerException
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:731)
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:642)
>   at org.apache.solr.util.SolrCLI$CreateTool.runImpl(SolrCLI.java:1773)
>   at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:176)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:282)
> {code}
> Looking at the code, this happened because SolrCLI got a 
> ClientProtocolException in its call to HttpClient, but that exception did NOT 
> have a message string attached, so when the code in the catch block tried to 
> look at the message, it threw NPE.



--
This message was sent by Atlassian 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-12206) SolrCLI can swallow all information about an exception from a request to Solr

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12206:
-

The user in this situation had enabled SSL on their Solr instance.  My best 
guess about what happened is that SolrCLI was unable to validate the 
certificate sent by the server.

 

> SolrCLI can swallow all information about an exception from a request to Solr
> -
>
> Key: SOLR-12206
> URL: https://issues.apache.org/jira/browse/SOLR-12206
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
>
> User got an NPE when trying to create a core, no useful information:
> {code}
> $ /usr/local/solr/bin/solr create -V -c new_core
> WARNING: Using _default configset with data driven schema functionality.
> NOT RECOMMENDED for production use.
>  To turn off: bin/solr config -c new_core -p 8983 -property
> update.autoCreateFields -value false
> Exception in thread "main" java.lang.NullPointerException
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:731)
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:642)
>   at org.apache.solr.util.SolrCLI$CreateTool.runImpl(SolrCLI.java:1773)
>   at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:176)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:282)
> {code}
> Looking at the code, this happened because SolrCLI got a 
> ClientProtocolException in its call to HttpClient, but that exception did NOT 
> have a message string attached, so when the code in the catch block tried to 
> look at the message, it threw NPE.



--
This message was sent by Atlassian 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-12206) SolrCLI can swallow all information about an exception from a request to Solr

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12206:
-

We should not assume that the exception will have a message.  Patch that might 
fix it:

{code}
diff --git a/solr/core/src/java/org/apache/solr/util/SolrCLI.java 
b/solr/core/src/java/org/apache/solr/util/SolrCLI.java
index a768a32157..f6c9df664f 100644
--- a/solr/core/src/java/org/apache/solr/util/SolrCLI.java
+++ b/solr/core/src/java/org/apache/solr/util/SolrCLI.java
@@ -728,9 +728,14 @@ public class SolrCLI {
 } catch (ClientProtocolException cpe) {
   // Currently detecting authentication by string-matching the HTTP 
response
   // Perhaps SolrClient should have thrown an exception itself??
-  if (cpe.getMessage().contains("HTTP ERROR 401") || 
cpe.getMessage().contentEquals("HTTP ERROR 403")) {
-int code = cpe.getMessage().contains("HTTP ERROR 401") ? 401 : 403; 
-throw new SolrException(SolrException.ErrorCode.getErrorCode(code), 
+  String msg = null;
+  if (cpe != null)
+  {
+msg = cpe.getMessage();
+  }
+  if (msg != null && (msg.contains("HTTP ERROR 401") || 
msg.contentEquals("HTTP ERROR 403"))) {
+int code = msg.contains("HTTP ERROR 401") ? 401 : 403;
+throw new SolrException(SolrException.ErrorCode.getErrorCode(code),
 "Solr requires authentication for " + getUrl + ". Please supply 
valid credentials. HTTP code=" + code);
   } else {
 throw cpe;
{code}


> SolrCLI can swallow all information about an exception from a request to Solr
> -
>
> Key: SOLR-12206
> URL: https://issues.apache.org/jira/browse/SOLR-12206
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
>
> User got an NPE when trying to create a core, no useful information:
> {code}
> $ /usr/local/solr/bin/solr create -V -c new_core
> WARNING: Using _default configset with data driven schema functionality.
> NOT RECOMMENDED for production use.
>  To turn off: bin/solr config -c new_core -p 8983 -property
> update.autoCreateFields -value false
> Exception in thread "main" java.lang.NullPointerException
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:731)
>   at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:642)
>   at org.apache.solr.util.SolrCLI$CreateTool.runImpl(SolrCLI.java:1773)
>   at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:176)
>   at org.apache.solr.util.SolrCLI.main(SolrCLI.java:282)
> {code}
> Looking at the code, this happened because SolrCLI got a 
> ClientProtocolException in its call to HttpClient, but that exception did NOT 
> have a message string attached, so when the code in the catch block tried to 
> look at the message, it threw NPE.



--
This message was sent by Atlassian 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&focusedCommentId=16431518#comment-16431518
 ] 

Karl Wright commented on LUCENE-8245:
-

Here's the output of the two edges that get considered in this case:

{code}
   [junit4]   1> Considering edge [lat=1.5463873005088208E-34, lon=0.0([X=1.0, 
Y=0.0, Z=1.5463873005088208E-34])] -> [lat=-0.08842062843650192, 
lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, 
Z=-0.08830545832969094])]
   [junit4]   1> Looking for intersection between plane [A=0.0, B=0.0; C=1.0; 
D=-2.330673801245995E-13] and plane [A=-1.5358762834889417E-34, 
B=0.11639624844359603; C=0.9932028560914717; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   return no solutions
   [junit4]   1> Looking for intersection between plane [A=0.0, B=1.0; C=0.0; 
D=-0.7784765265847915] and plane [A=-1.5358762834889417E-34, 
B=0.11639624844359603; C=0.9932028560914717; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   return no solutions
   
   [junit4]   1> Considering edge [lat=-0.08842062843650192, 
lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, 
Z=-0.08830545832969094])] -> [lat=0.379731892927642, 
lon=2.3485766139444504([X=-0.651713420845267, Y=0.6617191814215959, 
Z=0.370671474528177])]
   [junit4]   1> Looking for intersection between plane [A=0.0, B=0.0; C=1.0; 
D=-2.330673801245995E-13] and plane [A=0.7421702138887571, 
B=0.6571273907443821; C=0.1317837848515384; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   return no solutions
   [junit4]   1> Looking for intersection between plane [A=0.0, B=1.0; C=0.0; 
D=-0.7784765265847915] and plane [A=0.7421702138887571, B=0.6571273907443821; 
C=0.1317837848515384; D=0.0] within bounds
   [junit4]   1>  no solutions - no intersection
   [junit4]   1> Considering edge [lat=0.7779906922732096, 
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, 
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, 
Z=1.5463873005088208E-34])]
   [junit4]   1> Looking for intersection between plane [A=0.0, B=0.0; C=1.0; 
D=-2.330673801245995E-13] and plane [A=5.837507846237386E-35, 
B=0.9260123314536496; C=-0.377493260861404; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   returning 1 solution
   [junit4]   1>   Travel inner point [X=1.0, Y=9.103203687613759E-13, 
Z=2.2330673801246004E-12]; edgeplane=-1.0097419586828951E-28; 
travelInsidePlane=4.0389678347315804E-28; edgestartplane=0.7579267927410742; 
edgeendplane=-2.4114877353945626E-12
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>  Edge added 0 to outerCrossingCount
{code}

The second edge is detected as an intersection, but as you surmised, the first 
is not, even though it's properly found out of the tree.

The reason it's rejected is because of bounds; two points of intersection are 
in fact found, but apparently the bounding planes operate a bit too strenuously 
and do not permit either intersection point to remain.

It should be possible to bypass this case, however, since the case we're trying 
to catch is when an edge's endpoint is actually on the travel plane.  In that 
case, we've already got an intersection point to check.  I'll see if that 
solves this problem. 



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



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

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

[jira] [Created] (SOLR-12206) SolrCLI can swallow all information about an exception from a request to Solr

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-12206:
---

 Summary: SolrCLI can swallow all information about an exception 
from a request to Solr
 Key: SOLR-12206
 URL: https://issues.apache.org/jira/browse/SOLR-12206
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: 7.3
Reporter: Shawn Heisey
Assignee: Shawn Heisey


User got an NPE when trying to create a core, no useful information:

{code}
$ /usr/local/solr/bin/solr create -V -c new_core

WARNING: Using _default configset with data driven schema functionality.
NOT RECOMMENDED for production use.
 To turn off: bin/solr config -c new_core -p 8983 -property
update.autoCreateFields -value false
Exception in thread "main" java.lang.NullPointerException
at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:731)
at org.apache.solr.util.SolrCLI.getJson(SolrCLI.java:642)
at org.apache.solr.util.SolrCLI$CreateTool.runImpl(SolrCLI.java:1773)
at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:176)
at org.apache.solr.util.SolrCLI.main(SolrCLI.java:282)
{code}

Looking at the code, this happened because SolrCLI got a 
ClientProtocolException in its call to HttpClient, but that exception did NOT 
have a message string attached, so when the code in the catch block tried to 
look at the message, it threw NPE.




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

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 1682 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1682/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 5

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 5
at 
__randomizedtesting.SeedInfo.seed([915FEF9A27F394D6:AE481C26AABA688]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:379)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test

Error Message:
mismatch: 'These guys develop stuff'!='These guys help customers' @ 
response/docs/[0]/depts/docs/[0]/text_t

Stack Trace:
java.lang.AssertionError: mismatch: 'These guys develop stuff'!='These guys 
help custom

[jira] [Commented] (SOLR-10036) Revise jackson-core version from 2.5.4 to latest

[Kevin Cowan (JIRA)]

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

Kevin Cowan commented on SOLR-10036:


I wanted to provide a bit of testing information on this issue:

 

I replaced jackson core/databind/annotations 2.5.4 with version 2.9.5. I did 
NOT replace jackson-dataformat-smile 2.5.4 at this point. Just FYI, this jar 
has since been deprecated and is now part of the jackson-dataformat-binary 
module.

After replacing these .jars I was able to start Solr, create a new core, create 
a new collection, alter the schema, index and query json. I have noted no 
errors.

 

 

> Revise jackson-core version from 2.5.4 to latest
> 
>
> Key: SOLR-10036
> URL: https://issues.apache.org/jira/browse/SOLR-10036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shashank Pedamallu
>Priority: Major
> Attachments: SOLR-10036.patch
>
>
> The current jackson-core dependency in Solr is not compatible with Amazon AWS 
> S3 dependency. AWS S3 requires jackson-core-2.6.6 while Solr uses 
> jackson-core-dependency-2.5.4. This is blocking the usage of latest updates 
> from S3.
> It would be greatly helpful if someone could revise the jackson-core jar in 
> Solr to the latest version. This is a ShowStopper for our Public company.
> Details of my Setup:
> Solr Version: 6.3
> AWS SDK version: 1.11.76



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright edited comment on LUCENE-8245 at 4/9/18 10:52 PM:
--

[~ivera], that case should not occur.  The shared endpoint of two edges must 
either be in the +/- 1e-12 zone of main travel plane, or it's outside.  If it's 
within that zone, then BOTH edges should show up as an intersection candidate.

The tree structures underneath the edge iterator may be the problem, since I 
don't believe they include the necessary 1e-12 extra bounds needed to guarantee 
that we compute the intersection.  That's what I'm going to look for, since in 
the dump above it doesn't appear like we even consider more than one edge in 
the iterator.



was (Author: kwri...@metacarta.com):
[~ivera], that case should not occur.  The shared endpoint of two edges must 
either be in the +/- 1e-12 zone of main travel plane, or it's outside.  If it's 
within that zone, then BOTH edges should show up as an intersection candidate.

The tree structures underneath the edge iterator may be the problem, since I 
don't believe they include the necessary 1e-12 extra bounds needed to guarantee 
that we compute the intersection.  That's what I'm going to look for.


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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8245:
-

[~ivera], that case should not occur.  The shared endpoint of two edges must 
either be in the +/- 1e-12 zone of main travel plane, or it's outside.  If it's 
within that zone, then BOTH edges should show up as an intersection candidate.

The tree structures underneath the edge iterator may be the problem, since I 
don't believe they include the necessary 1e-12 extra bounds needed to guarantee 
that we compute the intersection.  That's what I'm going to look for.


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



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 34 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/34/

1 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:52931/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:47082/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[https://127.0.0.1:52931/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:47082/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([B5BA6B803F8F7F6D:1F77B872885CAABD]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:310)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  
org.apache.lucene.spatial.spatial4j.Geo3dShapeWGS84ModelRectRelationTest.testGeoPolygonRect

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([389CD4FDC599FC2D:587BE00A27B86BE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.locationtech.spatial4j.shape.RandomizedShapeTest.randomPointIn(RandomizedShapeTest.java:250)
at 
org.apache.lucene.spatial.spatial4j.ShapeRectRelationTestCase$3.generateRandomShape(ShapeRectRelationTestCase.java:133)
at 
org.locationtech.spatial4j.shape.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:98)
at 
org.apache.lucene.spatial.spatial4j.ShapeRectRelationTestCase.testGeoPolygonRect(ShapeRectRelationTestCase.java:157)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.lucene.spatial.spatial4j.Geo3dShapeWGS

[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&focusedCommentId=16431447#comment-16431447
 ] 

Karl Wright commented on LUCENE-8245:
-

Ok, this is the debug output of the now-failing test:

{code}
   [junit4] Suite: org.apache.lucene.spatial3d.geom.GeoPolygonTest
   [junit4]   1> Considering edge [lat=1.5463873005088208E-34, lon=0.0([X=1.0, 
Y=0.0, Z=1.5463873005088208E-34])] -> [lat=-0.08842062843650192, 
lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, 
Z=-0.08830545832969094])]
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint 
planes:
   [junit4]   1> Travel plane: [lat=0.7779906922732096, 
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, 
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, 
Z=1.5463873005088208E-34])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.08842062843650192, 
lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, 
Z=-0.08830545832969094])] -> [lat=0.379731892927642, 
lon=2.3485766139444504([X=-0.651713420845267, Y=0.
6617191814215959, Z=0.370671474528177])]
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint 
planes:
   [junit4]   1> Travel plane: [lat=0.7779906922732096, 
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, 
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, 
Z=1.5463873005088208E-34])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=0.7779906922732096, 
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, 
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, 
Z=1.5463873005088208E-34])]

   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint 
planes:
   [junit4]   1> Travel plane: [lat=0.7779906922732096, 
lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, 
Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, 
Z=1.5463873005088208E-34])]
   [junit4]   1>
   [junit4]   1>  start point travel dist=0.7018495564156595; end point travel 
dist=-2.330673801245995E-13
   [junit4]   1>  start point travel above dist=0.7018495564176594; end point 
travel above dist=1.7669326198754006E-12
   [junit4]   1>  start point travel below dist=0.7018495564136594; end point 
travel below dist=-2.2330673801246E-12
   [junit4]   1>  start point testpoint dist=-0.4923642700993317; end point 
testpoint dist=-0.7784765265847915
   [junit4]   1>  start point testpoint above dist=-0.49236427009733164; end 
point testpoint above dist=-0.7784765265827914
   [junit4]   1>  start point testpoint below dist=-0.49236427010133177; end 
point testpoint below dist=-0.7784765265867916
   [junit4]   1>   Travel inner point [X=1.0, Y=9.103203687613759E-13, 
Z=2.2330673801246004E-12]; edgeplane=-1.0097419586828951E-28; 
travelInsidePlane=4.0389678347315804E-28; edgestartplane=0.7579267927410742; 
edgeendplane=-2.4114877353945626E-12
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>  Edge added 0 to outerCrossingCount
   [junit4] FAILURE 0.16s | GeoPolygonTest.testAboveBelowCrossingDifferentEdges 
<<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4]>at 
org.apache.lucene.spatial3d.geom.GeoPolygonTest.testAboveBelowCrossingDifferentEdges(GeoPolygonTest.java:1486)
   [junit4] Completed [1/1 (1!)] in 0.17s, 1 test, 1 failure <<< FAILURES!
{code}


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



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

-

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

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-12205.
---
   Resolution: Fixed
Fix Version/s: 7.4

Committed your patch, thanks [~dancollins]!

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



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

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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-7887:
---

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

SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized 
annotation processing directive


> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-fix-maven-compilation.patch, 
> SOLR-7887-followup_1.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



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

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12205:


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

SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized 
annotation processing directive


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



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

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12205:


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

SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized 
annotation processing directive


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



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

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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-7887:
---

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

SOLR-12205,SOLR-7887: fix maven javadoc generation by removing unrecognized 
annotation processing directive


> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-fix-maven-compilation.patch, 
> SOLR-7887-followup_1.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



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

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

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

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-12205:
-

Assignee: Steve Rowe

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



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2481 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2481/

1 tests failed.
FAILED:  org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test

Error Message:
mismatch: 'These guys help customers'!='These guys develop stuff' @ 
response/docs/[0]/depts/docs/[0]/text_t

Stack Trace:
java.lang.AssertionError: mismatch: 'These guys help customers'!='These guys 
develop stuff' @ response/docs/[0]/depts/docs/[0]/text_t
at 
__randomizedtesting.SeedInfo.seed([2FD1598AA7C008EF:A7856650093C6517]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test(TestSubQueryTransformerDistrib.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14426 lines...]
   [junit4] Suite: 
org.apache.solr.response.transform.TestSubQueryTran

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

[Daniel Collins (JIRA)]

Daniel Collins created SOLR-12205:
-

 Summary: SOLR-7887 broke javadoc:jar in maven
 Key: SOLR-12205
 URL: https://issues.apache.org/jira/browse/SOLR-12205
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build
Affects Versions: 7.3, master (8.0)
Reporter: Daniel Collins


Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the 
javadoc command line.  That is not a javadoc option, so mvn javadoc:jar fails 
both on master and branch_7x.

The following fix works for me:
{code:java}
diff --git a/dev-tools/maven/pom.xml.template b/dev-tools/maven/pom.xml.template
index 4e21ca0e13..50299a3cda 100644
--- a/dev-tools/maven/pom.xml.template
+++ b/dev-tools/maven/pom.xml.template
@@ -238,7 +238,6 @@
true
-Xdoclint:all
-Xdoclint:-missing
- -proc:none



{code}
The ant build is fine, its just the maven build which is affected.



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

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

[jira] [Commented] (SOLR-11251) Ref Guide: Add docs on JSON facet module

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-11251:
-

I want to rephrase [the suggestion regarding 
debugging|https://lucene.apache.org/solr/guide/7_1/json-request-api.html#debugging].
bq. If you want to see what your merged/parsed JSON looks like, you can turn on 
debugging (debug=true), and it will come back under the "json" key along with 
the other debugging information.
This suggestion doesn't work on large indices, {{debug=true}} as well as 
{{debugQuery=true}} just never get back due to overall burden. The situation is 
even tricker since {{debug=query}} isn't propagated to slaves in the 
distributed search. The option I've found is {{debug=timing}}, which works like 
a charm but lacks of cluelessness. Should we put as just as 
bq. If you want to see what your merged/parsed JSON looks like, you can turn on 
debugging (debug=timing), and it will come back under the "json" key along with 
the other debugging information. 
Or also mention such caveat/explanations as well (which might be good for SEO 
reasons, btw).
bq. Note: that debug=true as well as debugQuery=true might have enormous impact 
on request time, and debug=true is ignored for json.facet.  

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



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

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

[jira] [Updated] (SOLR-12203) Error in response for field containing date. Unexpected state.

[Jeroen Steggink (JIRA)]

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

Jeroen Steggink updated SOLR-12203:
---
Description: 
I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field: 
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at 
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at 
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at 
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
at 
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
at 
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
at 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748){noformat}
I can't find out why this occurs. The weird thing is, I can't seem to find this 
field (ds_lastModified) in the schema. I tried looking it up using Luke, but 
also no result (/solr/some-core/admin/luke?fl=ds_lastModified). I do know that 
at some point there were documents with this field. Seems like a bug. Any idea?

 

  was:
I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field: 
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at 
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at 
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at 
org.apache.solr.response.JSONWriter.writeNamedLis

[jira] [Closed] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods

[JIRA]

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

Jan Høydahl closed SOLR-10453.
--

> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}} 
> setter on all {{SolrClient}} implementations.



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

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

[jira] [Assigned] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods

[JIRA]

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

Jan Høydahl reassigned SOLR-10453:
--

Assignee: (was: Jan Høydahl)

> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}} 
> setter on all {{SolrClient}} implementations.



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

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

[jira] [Reopened] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods

[JIRA]

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

Jan Høydahl reopened SOLR-10453:


> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}} 
> setter on all {{SolrClient}} implementations.



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

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

[jira] [Resolved] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods

[JIRA]

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

Jan Høydahl resolved SOLR-10453.

Resolution: Invalid

Marking as invalid

> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}} 
> setter on all {{SolrClient}} implementations.



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

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

[jira] [Commented] (SOLR-10453) setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-10453:


When I created this a while back, it was in a group of related stories centered 
around making our {{SolrClient}} implementations more immutable (and hopefully 
safer for multi-threading).  In generating those JIRAs, I grabbed a list of all 
the "setters" I saw, and must have missed that this one was 
internal/not-a-setter.

So to answer your actual question, I don't think this is a duplicate of 
SOLR-12194, but you were right to close it (if only because it's invalid).

> setBasicAuthHeader should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10453
> URL: https://issues.apache.org/jira/browse/SOLR-10453
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 7.0
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setBasicAuthHeader}} 
> setter on all {{SolrClient}} implementations.



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

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.4) - Build # 537 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/537/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC

9 tests failed.
FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:
--> http://127.0.0.1:50090/collection1_shard2_replica_n41:Failed to execute 
sqlQuery 'select id, field_i, str_s from collection1 where (text='()' OR 
text='') AND text='' order by field_i desc' against JDBC connection 
'jdbc:calcitesolr:'. Error while executing SQL "select id, field_i, str_s from 
collection1 where (text='()' OR text='') AND text='' order by 
field_i desc": java.io.IOException: java.util.concurrent.ExecutionException: 
java.io.IOException: --> 
http://127.0.0.1:50162/collection1_shard2_replica_n45/:can not sort on a field 
w/o docValues unless it is indexed and supports Uninversion: field_i

Stack Trace:
java.io.IOException: --> 
http://127.0.0.1:50090/collection1_shard2_replica_n41:Failed to execute 
sqlQuery 'select id, field_i, str_s from collection1 where (text='()' OR 
text='') AND text='' order by field_i desc' against JDBC connection 
'jdbc:calcitesolr:'.
Error while executing SQL "select id, field_i, str_s from collection1 where 
(text='()' OR text='') AND text='' order by field_i desc": 
java.io.IOException: java.util.concurrent.ExecutionException: 
java.io.IOException: --> 
http://127.0.0.1:50162/collection1_shard2_replica_n45/:can not sort on a field 
w/o docValues unless it is indexed and supports Uninversion: field_i
at 
__randomizedtesting.SeedInfo.seed([C179A84DEEA46BDE:663D10E9831F7867]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:222)
at 
org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2522)
at 
org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:124)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:82)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:

[JENKINS] Lucene-Solr-Tests-7.x - Build # 555 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/555/

4 tests failed.
FAILED:  org.apache.solr.cloud.CreateRoutedAliasTest.testV1

Error Message:
Error from server at http://127.0.0.1:43553/solr: Collection : 
testV2_2018-04-09 is part of alias testV2 remove or modify the alias before 
removing this collection.

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:43553/solr: Collection : testV2_2018-04-09 is 
part of alias testV2 remove or modify the alias before removing this collection.
at 
__randomizedtesting.SeedInfo.seed([85419656E30CFDC1:2A8F5126A2E15151]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:451)
at 
org.apache.solr.cloud.CreateRoutedAliasTest.doBefore(CreateRoutedAliasTest.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:968)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java

BeastIt! Report for Apache Solr Master

[BeastIt BeastIt]

BeastIt Unit Test Beasting Summary Report for Apache Solr Master

BeastIt gives unit tests a chance to duke it out in a fair but difficult
environment. Each test is beasted and then judged. See a link to the full
reports below.

Number of Tests: 
Number Passed: 1077
% Passed: 96.94%

Ran 30 iterations, 5 at a time

Markers (Marked tests have one of these markers)
 @AwaitsFix: 1
 @BadApple: 12
 @Ignore: 3

 *** Worst Test - Not Marked (It's your Moby Dick!)

 - TestTriggerIntegration 66% half–cracked ''

  If you catch that whale, next try
   - TestSubQueryTransformerDistrib 30% unreliable ''

 *** New Test(s) Failing?! Sound the alarm, we may have a cowboy here.

 - NodeAddedTriggerIntegrationTest 3% flakey

 *** New Failures in Test(s)?! Everything looked so good!

 - HdfsBasicDistributedZkTest 3% flakey was 0,0,0,0
 - ForceLeaderTest 3% flakey was 0,0,0,0
 - TestRandomRequestDistribution 3% flakey was 0,0,0,0
 - TestSubQueryTransformerDistrib 30% unreliable was 0,0,0,0
 - TestV2Request 3% flakey was 0,0,0,0
 - TestLeaderInitiatedRecoveryThread 3% flakey was 0,0,0,0
 - NodeAddedTriggerIntegrationTest 3% flakey was 0
 - NodeAddedTriggerTest 30% unreliable was 0,0,0,0

 *** Slowest Test

 - CdcrReplicationDistributedZkTest 1752.99 unreliable '@BadApple @Nightly
' Can you speed me up?

 *** Worst Test - Marked (How long must it suffer the mark?)

 - CdcrReplicationDistributedZkTest 23% unreliable '@BadApple @Nightly  '

 *** Non Running Tests - Coverage Holes?!

 - ChaosMonkeyShardSplitTest '@Ignore '
 - TestRankQueryPlugin '@Ignore '
 - TestMailEntityProcessor '@Ignore '


Full Reports http://apache-solr.bitballoon.com

(Report maintained by Mark Miller)

[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&focusedCommentId=16430990#comment-16430990
 ] 

Walter Underwood commented on SOLR-11971:
-

Is there a workaround for this that does not require upgrading?

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



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

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

Re: Potential BadApple report this week

[Erick Erickson]

Cool. I'll put them on my permanent "don't BadApple" list. If they're
still there in a month I'll ask again

And for everyone. I have no objection at all to leaving failing tests
in if people are working on them. I realize that sometimes the only
way to get them to fail is to leave them running

Erick



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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-11-ea+5) - Build # 7260 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7260/
Java: 64bit/jdk-11-ea+5 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

5 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 6

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 6
at 
__randomizedtesting.SeedInfo.seed([B4AF423516FBAB72:2F142C6D5BA3992C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:379)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:841)


FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([B4AF423516FBAB72:7D1A009B1F9C6D87]:0)
at org.junit

[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&focusedCommentId=16430935#comment-16430935
 ] 

Ignacio Vera commented on LUCENE-8245:
--

I can give you an answer why it fails: In that case the planes above and below 
cross different edges. Because we only consider edges that crosses the main 
plain we miss one cross.

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



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

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

[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&focusedCommentId=16430931#comment-16430931
 ] 

Karl Wright commented on LUCENE-8245:
-

Reasoning this through, the spacing between the travel plane and the above or 
below plane should be exactly 2.0 * MINIMUM_RESOLUTION.  That will guarantee 
that any point that falls between the two planes is detected in one or the 
other (or, very rarely, both).  When I set it up this way, the LUCENE8245 test 
starts passing, but the testAboveBelowCrossingDifferentEdges example now fails. 
 So I will next analyze why that occurs, and see if the problem in that case is 
more readily addressable.


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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8245:
-

For fun, I tried to set it up so that the edge cutoff planes had a smaller 
MINIMUM_RESOLUTION they used than everything else.  This unexpectedly broke 
everything.  So then I tried having a smaller MINIMUM_RESOLUTION just for the 
start/end planes for edges.  This allowed me to get the current failing test to 
start passing, but the other tests committed on the weekend started failing 
instead.  In fact, I could find a value for this that's not much different than 
MINIMUM_RESOLUTION that led to ALL the complex polygon tests failing.  That's a 
rather worrisome development.


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



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

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

Re: Potential BadApple report this week

[Steve Rowe]

Hi Erick,

Please don’t BadApple any TestReplicationHandler tests, I’m looking at them 
this week:

  org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication
  org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl
  org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Thanks,

--
Steve
www.lucidworks.com

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

BadApple 2

[Erick Erickson]

Here are the failures in the last week by (rough) category:

*No ZK node NoNode
junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.JDBCStreamTest

*Timeout (or time related)/session expired/thread
leak/zombie threads/Object tracker
junit.framework.TestSuite.org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat
junit.framework.TestSuite.org.apache.lucene.codecs.perfield.TestPerFieldDocValuesFormat
junit.framework.TestSuite.org.apache.lucene.index.TestIndexSorting
junit.framework.TestSuite.org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyFieldFacetExtrasCloudTest
junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamDecoratorTest
junit.framework.TestSuite.org.apache.solr.cloud.cdcr.CdcrBootstrapTest
junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest
junit.framework.TestSuite.org.apache.solr.cloud.TestLeaderElectionZkExpiry
junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest
junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest
SOLR-12200 ZkControllerTest failure. Leaking Overseer
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler
junit.framework.TestSuite.org.apache.solr.response.transform.TestSubQueryTransformerDistrib
junit.framework.TestSuite.org.apache.solr.uninverting.TestDocTermOrds
junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample
org.apache.lucene.codecs.lucene70.TestLucene70DocValuesFormat.testGCDCompression
org.apache.lucene.codecs.perfield.TestPerFieldDocValuesFormat.testSparseBinaryFixedLengthVsStoredFields
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication


***OutOfMemory/GC overhead exceeded. DON'T BADAPPLE THESE?
org.apache.lucene.index.TestIndexWriterOnVMError.testOOM
org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention
org.apache.lucene.search.TestCustomSearcherSort.testFieldSortCustomSearcher
org.apache.lucene.search.TestCustomSearcherSort.testFieldSortSingleSearcher
org.apache.solr.uninverting.TestDocTermOrds.testActuallySingleValued
org.apache.solr.uninverting.TestDocTermOrds.testBackToTheFuture
org.apache.solr.uninverting.TestDocTermOrds.testRandom
org.apache.solr.uninverting.TestDocTermOrds.testRandomWithPrefix
org.apache.solr.uninverting.TestDocTermOrds.testSimple
org.apache.solr.uninverting.TestDocTermOrds.testSortedTermsEnum
org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit
org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit
SOLR-12147 TestDocTermOrds.testTriggerUnInvertLimit should not use
MemoryCodec


**No Live Servers/Could not find collection
org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete


**Error starting mini SolrCloud cluster


**I/O Exception

**Mock Directory (open files)

*Other (typically asserts.)
junit.framework.TestSuite.org.apache.lucene.search.TestCustomSearcherSort
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyFieldFacetExtrasCloudTest
junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamingTest
junit.framework.TestSuite.org.apache.solr.common.cloud.TestCollectionStateWatchers
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin
org.apache.lucene.index.TestIndexSorting.testRandom3
org.apache.solr.client.solrj.io.stream.StreamDecoratorTest.testParallelExecutorStream
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testGammaDistribution
org.apache.solr.cloud.AddReplicaTest.test
org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1
org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testRestoreState
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling
org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent
org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate
org.apache.solr.cloud.CreateRoutedAliasTest.testV1
org.apache.solr.cloud.CreateRoutedAliasTest.testV2
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing
org.apache.solr.cloud.DistribCursorPagingTest.test
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly
org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest.test
org.apache.solr.cloud.hdfs.StressHdfsTest.test
org.apach

Potential BadApple report this week

[Erick Erickson]

OK, this is the first week I have Hoss' report from two weeks ago so
the list is rather lengthy.


I believe this test is being actively worked on, so no BadApple for it
   org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue

***Tests I'll BadApple on Thursday.

These are tests that failed in the last week and _also_ are failures
in Hoss' report from two weeks ago, so nobody has addressed them in
that time-frame.

PLEASE LET ME KNOW BEFORE THURSDAY WHICH OF THESE SHOULD NOT BE BADAPPLEd

   org.apache.lucene.index.TestIndexSorting.testRandom3
   org.apache.solr.TestDistributedSearch.test
   org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions
   org.apache.solr.cloud.AddReplicaTest.test
   org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1
   org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test
   org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent
   org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate
   org.apache.solr.cloud.CreateRoutedAliasTest.testV1
   org.apache.solr.cloud.CreateRoutedAliasTest.testV2
   org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing
   org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest
   org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState
   org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest
   
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete
   
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections
   org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger
   
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState
   
org.apache.solr.common.cloud.TestCollectionStateWatchers.testDeletionsTriggerWatches
   
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication
   org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl
   org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
   org.apache.solr.handler.TestReplicationHandler.doTestStressReplication
   org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory
   org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.test


***Tests currently BadApple-d

*AwaitsFix Annotations:


Lucene AwaitsFix
TestControlledRealTimeReopenThread.java
   testCRTReopen()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5737";)

TestICUNormalizer2CharFilter.java
   testRandomStrings()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-5595";)

TestMoreLikeThis.java
   testMultiFieldShouldReturnPerFieldBooleanQuery()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-7161";)

UIMABaseAnalyzerTest.java
   testRandomStrings()
   @Test @AwaitsFix(bugUrl =
"https://issues.apache.org/jira/browse/LUCENE-3869";)

UIMABaseAnalyzerTest.java
   testRandomStringsWithConfigurationParameters()
   @Test @AwaitsFix(bugUrl =
"https://issues.apache.org/jira/browse/LUCENE-3869";)

UIMATypeAwareAnalyzerTest.java
   testRandomStrings()
   @Test @AwaitsFix(bugUrl =
"https://issues.apache.org/jira/browse/LUCENE-3869";)


Solr AwaitsFix
ReplaceNodeNoTargetTest.java
   ReplaceNodeNoTargetTest suite
   @LuceneTestCase.AwaitsFix(bugUrl =
"https://issues.apache.org/jira/browse/SOLR-11067";)

TestCollapseQParserPlugin.java
   testStringCollapse()
   @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-11974";)

TestImpersonationWithHadoopAuth.java
   testForwarding()
   @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/HADOOP-9893";)

TestLTRReRankingPipeline.java
   testDifferentTopN()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/SOLR-11134";)

TestMinMaxOnMultiValuedField.java
   testDoubleFieldCache()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";)

TestMinMaxOnMultiValuedField.java
   testFloatFieldCache()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";)

TestMinMaxOnMultiValuedField.java
   testIntFieldCache()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";)

TestMinMaxOnMultiValuedField.java
   testLongFieldCache()
   @AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/LUCENE-6709";)



*BadApple Annotations:

Lucene BadApple
TestLRUQueryCache.java
   testDocValuesUpdatesDontBreakCache()
   @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";)


Solr BadApple
AliasIntegrationTest.java
   testModifyPropertiesCAR()
   @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";)

AliasIntegrationTest.java
   testProperties()
   @BadApple(bugUrl="https://issues.apache.org/jira/browse/SOLR-12028";)

AutoAddReplicasIntegrationTest.java
  

[jira] [Created] (SOLR-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[Hrishikesh Gadre (JIRA)]

Hrishikesh Gadre created SOLR-12204:
---

 Summary: Upgrade commons-fileupload to address CVE-2016-131
 Key: SOLR-12204
 URL: https://issues.apache.org/jira/browse/SOLR-12204
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.2
Reporter: Hrishikesh Gadre
Assignee: Hrishikesh Gadre


Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
susceptible to  CVE-2016-131. We should upgrade the this library to the 
latest version (1.3.3 at the time of writing) to mitigate the security risk.



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

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

[jira] [Commented] (SOLR-12139) Support "eq" function for string fields

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12139:


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

SOLR-12139: eq() now works on strings and perhaps anything

(cherry picked from commit f0aed93)


> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string 
> types as well?



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

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

[jira] [Commented] (SOLR-12139) Support "eq" function for string fields

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12139:


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

SOLR-12139: eq() now works on strings and perhaps anything


> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string 
> types as well?



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

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

[jira] [Commented] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory

[Boris Pasko (JIRA)]

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

Boris Pasko commented on SOLR-6305:
---

[~elyograg] you're absolutely right. For solr, HDFS is just another block 
storage. It does not use any HDFS-specific replication strategies, for example, 
copying files as Map/Reduce job. Therefore, having 3 solr replicas and default 
replication factor of 3 actually produces 3 data copies.

The storage space itself is typically less of the concern, the bigger concern 
is network traffic. Bytes that has to be moved to 3 datanodes instead of 1 
datanode.

> Ability to set the replication factor for index files created by 
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
>  Issue Type: Improvement
>  Components: hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Priority: Major
> Attachments: 
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different 
> replication factor than the configured DFS default because it uses: 
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using 
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication 
> factor for the Solr directories to a lower value than the default. I realize 
> this might reduce the chance of data locality but since Solr cores each have 
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the 
> replication factor, but that's a one-time shot and doesn't affect new files 
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an 
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent 
> directory.
> Not sure if we need to go as far as allowing different replication factor per 
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through 
> this using the Configuration object but nothing jumped out at me ... and the 
> implementation for getServerDefaults(path) is just:
>   public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
>   }
> Path is ignored ;-)



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

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

Re: [JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 196 - Failure

[Simon Willnauer]

this is an endless merge loop due to merge policy accounting issues
that were not implemented yet. I opened
https://issues.apache.org/jira/browse/LUCENE-8246

On Mon, Apr 9, 2018 at 12:19 PM, Simon Willnauer
 wrote:
> I am looking into this
>
> On Mon, Apr 9, 2018 at 12:06 PM, Apache Jenkins Server
>  wrote:
>> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/196/
>>
>> 5 tests failed.
>> FAILED:  
>> org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention
>>
>> Error Message:
>> GC overhead limit exceeded
>>
>> Stack Trace:
>> java.lang.OutOfMemoryError: GC overhead limit exceeded
>> at 
>> __randomizedtesting.SeedInfo.seed([248C95A59BE17434:3432A38A78701E91]:0)
>> at java.util.HashMap$KeySet.iterator(HashMap.java:917)
>> at java.util.HashSet.iterator(HashSet.java:173)
>> at 
>> org.apache.lucene.index.IndexWriter.maxNumSegmentsMergesPending(IndexWriter.java:2216)
>> at 
>> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2190)
>> at 
>> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2119)
>> at 
>> org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy.testSoftDeleteWithRetention(TestSoftDeletesRetentionMergePolicy.java:266)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
>> at 
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>> at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>> at 
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>> at 
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>> at 
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
>> at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
>> at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>> at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>>
>>
>> FAILED:  
>> junit.framework.TestSuite.org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy
>>
>> Error Message:
>> 2 threads leaked from SUITE scope at 
>> org.apache.lucene.index.TestSoftDeletesRetentionMergePolicy: 1) 
>> Thread[id=289762, name=Lucene Merge Thread #281215, state=RUNNABLE, 
>> group=TGRP-TestSoftDeletesRetentionMergePolicy] at 
>> java.lang.Thread.yield(Native Method) at 
>> org.apache.lucene.store.MockDirectoryWrapper.maybeYield(MockDirectoryWrapper.java:626)
>>  at 
>> org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:644)
>>  at 
>> org.apache.lucene.store.LockValidatingDirectoryWrapper.createOutput(LockValidatingDirectoryWrapper.java:44)
>>  at 
>> org.apache.lucene.index.ConcurrentMergeScheduler$1.createOutput(ConcurrentMergeSched

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

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10783:


Thanks Mano. I'll look at this again today.

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



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

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

[jira] [Updated] (SOLR-12203) Error in response for field containing date. Unexpected state.

[Jeroen Steggink (JIRA)]

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

Jeroen Steggink updated SOLR-12203:
---
Description: 
I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field: 
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at 
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at 
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at 
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
at 
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
at 
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
at 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748){noformat}
I can't find out why this occurs. The weird thing is, I can't seem to find this 
field (ds_lastModified) in the schema. I tried looking it up using Luke, but 
also no result (/solr/some-core/admin/luke?fl=ds_lastModified). I do know that 
at some point there were documents with this field. Seems like a bug. Any idea?

Not sure if it's related, but checking another DatePointField using Luke, I get 
the following error:
{noformat}
"java.lang.ArrayIndexOutOfBoundsException: 6\n\tat 
org.apache.lucene.util.NumericUtils.sortableBytesToLong(NumericUtils.java:183)\n\tat
 org.apache.lucene.document.LongPoint.decodeDimension(LongPoint.java:139)\n\tat 
org.apache.solr.schema.DatePointField.indexedToReadable(DatePointField.java:179)\n\tat
 org.apache.solr.schema.PointField.indexedToReadable(PointField.java:218)\n\tat 
org.apache.solr.handler.admin.LukeRequestHandler$TopTermQueue.toNamedList(LukeRequestHandler.java:792)\n\tat
 
org.apache.solr.handler.admin.LukeRequestHandler.getDetailedFieldInfo(LukeRequestHandler.java:688)\n\tat
 
org.apache.solr.han

[jira] [Created] (SOLR-12203) Error in response for field containing date. Unexpected state.

[Jeroen Steggink (JIRA)]

Jeroen Steggink created SOLR-12203:
--

 Summary: Error in response for field containing date. Unexpected 
state.
 Key: SOLR-12203
 URL: https://issues.apache.org/jira/browse/SOLR-12203
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Affects Versions: 7.2.1, 7.3
Reporter: Jeroen Steggink


I get the following error:
{noformat}
java.lang.AssertionError: Unexpected state. Field: 
'stored,indexed,tokenized,omitNorms,indexOptions=DOCS'
at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
at org.apache.solr.schema.PointField.write(PointField.java:198)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
at 
org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
at 
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
at 
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
at 
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
at 
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
at 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748){noformat}
I can't find out why this occurs. The weird thing is, I can't seem to find this 
field (ds_lastModified) in the schema. I tried looking it up using Luke, but 
also no result (/solr/some-core/admin/luke?fl=ds_lastModified). I do know that 
at some point there were documents with this field. Seems like a bug. Any idea?

 

 



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

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

[jira] [Resolved] (LUCENE-8242) Rename IndexSearcher.createNormalizedWeight()

[Alan Woodward (JIRA)]

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

Alan Woodward resolved LUCENE-8242.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4

Thanks for the reviews

> Rename IndexSearcher.createNormalizedWeight()
> -
>
> Key: LUCENE-8242
> URL: https://issues.apache.org/jira/browse/LUCENE-8242
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8242.patch
>
>
> We don't have Weight normalization since LUCENE-7368, so this method name is 
> just plain wrong.



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

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

[jira] [Commented] (LUCENE-8242) Rename IndexSearcher.createNormalizedWeight()

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8242: Remove IndexSearcher.createNormalizedWeight


> Rename IndexSearcher.createNormalizedWeight()
> -
>
> Key: LUCENE-8242
> URL: https://issues.apache.org/jira/browse/LUCENE-8242
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8242.patch
>
>
> We don't have Weight normalization since LUCENE-7368, so this method name is 
> just plain wrong.



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

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

[jira] [Commented] (LUCENE-8242) Rename IndexSearcher.createNormalizedWeight()

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8242: Deprecate createNormalizedWeight


> Rename IndexSearcher.createNormalizedWeight()
> -
>
> Key: LUCENE-8242
> URL: https://issues.apache.org/jira/browse/LUCENE-8242
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8242.patch
>
>
> We don't have Weight normalization since LUCENE-7368, so this method name is 
> just plain wrong.



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

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

[jira] [Commented] (LUCENE-8242) Rename IndexSearcher.createNormalizedWeight()

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8242: Deprecate createNormalizedWeight


> Rename IndexSearcher.createNormalizedWeight()
> -
>
> Key: LUCENE-8242
> URL: https://issues.apache.org/jira/browse/LUCENE-8242
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8242.patch
>
>
> We don't have Weight normalization since LUCENE-7368, so this method name is 
> just plain wrong.



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

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

[jira] [Commented] (SOLR-9562) Minimize queried collections for time series alias

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9562:


Mosh, I suppose you meant that CloudSolrClient could determine the set of 
collections to be searched at its side and then send them via 
{{collection=}} That's possible... but if done at the Solr side then 
clients other than Java could leverage this.

> Minimize queried collections for time series alias
> --
>
> Key: SOLR-9562
> URL: https://issues.apache.org/jira/browse/SOLR-9562
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Eungsop Yoo
>Priority: Minor
> Attachments: SOLR-9562-v2.patch, SOLR-9562.patch
>
>
> For indexing time series data(such as large log data), we can create a new 
> collection regularly(hourly, daily, etc.) with a write alias and create a 
> read alias for all of those collections. But all of the collections of the 
> read alias are queried even if we search over very narrow time window. In 
> this case, the docs to be queried may be stored in very small portion of 
> collections. So we don't need to do that.
> I suggest this patch for read alias to minimize queried collections. Three 
> parameters for CREATEALIAS action are added.
> || Key || Type || Required || Default || Description ||
> | timeField | string | No | | The time field name for time series data. It 
> should be date type. |
> | dateTimeFormat | string | No | | The format of timestamp for collection 
> creation. Every collection should has a suffix(start with "_") with this 
> format. 
> Ex. dateTimeFormat: MMdd, collectionName: col_20160927
> See 
> [DateTimeFormatter|https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html].
>  |
> | timeZone | string | No | | The time zone information for dateTimeFormat 
> parameter.
> Ex. GMT+9. 
> See 
> [DateTimeFormatter|https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html].
>  |
> And then when we query with filter query like this "timeField:\[fromTime TO 
> toTime\]", only the collections have the docs for a given time range will be 
> queried.



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

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

Re: TestPerFieldDocValuesFormat timeout

[Erick Erickson]

Dawid:

It's certainly possible. I'm working on LUCENE-7976 and one of my
attempts did exactly that. There's a tricky bit of code there where a
forceMerge merges some segments and then gets called again for them to
get merged in turn (this to respect maxMergeAtOnceExplicit which
defaults to 30). If the logic was  a bit off it could keep going.

I think another place I messed up was when the merging didn't have
maxMergeAtOnce segments. one of the find*Merges kept being called
because there were segments to merge but never merged any because of a
faulty conditional.

I took a quick look at the test output and don't see _what_ merge
policy is being used though. I _don't_ think TMP has this problem, but
don't know about any of the other merge policies.

In the FWIW category, TMP.findMerges() gets a MergeTrigger as a
parameter but then totally ignores it (even in the current code).

Erick


On Mon, Apr 9, 2018 at 1:06 AM, Dawid Weiss  wrote:
> There is an odd timeout failure here:
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/195/consoleFull
>
> The TestPerFieldDocValuesFormat timed out. The stack trace shows just
> one relevant thread in the enforced index merge, never returning from
> the loop awaiting the number of segments to reach the desired number.
> Is it possible that the merge policy ignores MergeTrigger.EXPLICIT
> this this results in an endless loop?
>
>[junit4]   2>4) Thread[id=12,
> name=TEST-TestPerFieldDocValuesFormat.testSparseBinaryFixedLengthVsStoredFields-seed#[617399315453E295],
> state=TIMED_WAITING, group=TGRP-TestPerFieldDocValuesFormat]
>[junit4]   2> at java.lang.Object.wait(Native Method)
>[junit4]   2> at
> org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4716)
>[junit4]   2> at
> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2191)
>[junit4]   2> at
> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2119)
>[junit4]   2> at
> org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:445)
>[junit4]   2> at
> org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestBinaryVsStoredFields(BaseDocValuesFormatTestCase.java:1472)
>[junit4]   2> at
> org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestBinaryFixedLengthVsStoredFields(BaseDocValuesFormatTestCase.java:1508)
>[junit4]   2> at
> org.apache.lucene.index.BaseDocValuesFormatTestCase.testSparseBinaryFixedLengthVsStoredFields(BaseDocValuesFormatTestCase.java:1501)
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2480/

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testRestoreState

Error Message:
Did not expect the processor to fire on first run! event={   
"id":"13f45dd0dc99d3T2mp8mcx8wnw5re9d8a10cs8zd",   
"source":"node_added_trigger",   "eventTime":5616708330756563,   
"eventType":"NODEADDED",   "properties":{ "eventTimes":[   
5616708330756563,   5616708330758428,   5616708330759165,   
5616708330759848], "nodeNames":[   "127.0.0.1:38746_solr",   
"127.0.0.1:37070_solr",   "127.0.0.1:33003_solr",   
"127.0.0.1:37817_solr"]}}

Stack Trace:
java.lang.AssertionError: Did not expect the processor to fire on first run! 
event={
  "id":"13f45dd0dc99d3T2mp8mcx8wnw5re9d8a10cs8zd",
  "source":"node_added_trigger",
  "eventTime":5616708330756563,
  "eventType":"NODEADDED",
  "properties":{
"eventTimes":[
  5616708330756563,
  5616708330758428,
  5616708330759165,
  5616708330759848],
"nodeNames":[
  "127.0.0.1:38746_solr",
  "127.0.0.1:37070_solr",
  "127.0.0.1:33003_solr",
  "127.0.0.1:37817_solr"]}}
at 
__randomizedtesting.SeedInfo.seed([FBB595EFC01A88B8:351B317C3823F0AE]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.lambda$new$0(NodeAddedTriggerTest.java:49)
at 
org.apache.solr.cloud.autoscaling.NodeAddedTrigger.run(NodeAddedTrigger.java:161)
at 
org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testRestoreState(NodeAddedTriggerTest.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementA

[jira] [Commented] (SOLR-12139) Support "eq" function for string fields

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev commented on SOLR-12139:
---

Good work, David. I just added couple more tests for cases mentioned above 
(varying types, i.e. string - numeric comparisons, null values)

> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string 
> types as well?



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

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

[jira] [Updated] (SOLR-12139) Support "eq" function for string fields

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev updated SOLR-12139:
--
Attachment: SOLR-12139.patch

> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch, 
> SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string 
> types as well?



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

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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl

Error Message:
expected: but was:<.numFound:500!=496>

Stack Trace:
java.lang.AssertionError: expected: but was:<.numFound:500!=496>
at 
__randomizedtesting.SeedInfo.seed([9AE936E4347BA6AE:8152C79B55C4DE18]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl(TestReplicationHandler.java:803)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


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

Error Message:
expected:<847> but was:<735>

Stack Trace:
java.lang.AssertionError: expected:<847

[jira] [Updated] (SOLR-12198) Stream Evaluators should not copy matrices needlessly

[Joel Bernstein (JIRA)]

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

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

> Stream Evaluators should not copy matrices needlessly
> -
>
> Key: SOLR-12198
> URL: https://issues.apache.org/jira/browse/SOLR-12198
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12198.patch
>
>
> Currently several of the Stream Evaluators that work with matrices are 
> creating multiple copies of the underlying multi-dimensional arrays. This can 
> lead to excessive memory usage. This ticket will change these implementations 
> so copies of the multi-dimensional arrays that back a matrix are only copied 
> when the *copyOf* function is used.



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

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

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

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-8246:
-

https://github.com/s1monw/lucene-solr/pull/10 FYI [~mikemccand]

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



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

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

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

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-8246:

Attachment: LUCENE-8246.patch

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



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

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

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

[Simon Willnauer (JIRA)]

Simon Willnauer created LUCENE-8246:
---

 Summary: Allow to customize the number of deletes a merge claims
 Key: LUCENE-8246
 URL: https://issues.apache.org/jira/browse/LUCENE-8246
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 7.4, master (8.0)
Reporter: Simon Willnauer
 Fix For: 7.4, master (8.0)


With the introduction of soft deletes no every merge claims all documents that 
are marked as deleted in the segment readers. MergePolicies still need to do 
accurate accounting in order to select segments for merging and need to decide 
if segments are merged. This chance allows the merge policy to customize the 
number of deletes a merge of a segment claims.



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

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 1679 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1679/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test

Error Message:
mismatch: 'These guys develop stuff'!='These guys help customers' @ 
response/docs/[0]/depts/docs/[0]/text_t

Stack Trace:
java.lang.AssertionError: mismatch: 'These guys develop stuff'!='These guys 
help customers' @ response/docs/[0]/depts/docs/[0]/text_t
at 
__randomizedtesting.SeedInfo.seed([BB76B7056B642F86:332288DFC598427E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test(TestSubQueryTransformerDistrib.java:166)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test

[jira] [Updated] (SOLR-12202) solr-exporter.cmd cannot be run on Windows

[Minoru Osuka (JIRA)]

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

Minoru Osuka updated SOLR-12202:

Attachment: SOLR-12202.patch

> solr-exporter.cmd cannot be run on Windows
> --
>
> Key: SOLR-12202
> URL: https://issues.apache.org/jira/browse/SOLR-12202
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Minoru Osuka
>Priority: Major
> Attachments: SOLR-12202.patch
>
>
> solr-exporter.cmd could not be run on Windows due to following:
> - incorrect main class name.
> - incorrect classpath specification.



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

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

[jira] [Commented] (LUCENE-8242) Rename IndexSearcher.createNormalizedWeight()

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8242:
--

+1 Maybe say that {{boost}} should be {{1}} in the {{@deprecated}} javadocs and 
add an entry to {{lucene/MIGRATE.txt}}?

> Rename IndexSearcher.createNormalizedWeight()
> -
>
> Key: LUCENE-8242
> URL: https://issues.apache.org/jira/browse/LUCENE-8242
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8242.patch
>
>
> We don't have Weight normalization since LUCENE-7368, so this method name is 
> just plain wrong.



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

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

[jira] [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&focusedCommentId=16430471#comment-16430471
 ] 

Karl Wright commented on LUCENE-8245:
-

Last bit of debugging until later:

{code}
   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, 
Z=-1.4926898632243605E-13]; edgeplane=2.5243548967072378E-29; 
travelOutsidePlane=-1.0097419586828951E-28; 
edgestartplane=-6.993093735168714E-13; edgeendplane=-0.6515740933786793
   [junit4]   1>  Edge added 1 to outerCrossingCount
{code}

The bad crossing point it finds is (it appears) on the wrong side of the edge's 
start cutoff plane, at a value of  -6.993093735168714E-13, which is *almost* 
big enough to get it kicked out, but not quite.

The interesting thing is that the precision of sidedness checks in general 
(which is what this is, in fact) is MUCH higher than 1e-12.  But if we 
decreased MINIMUM_RESOLUTION globally, we would not fix the issue, because the 
above/below planes get closer to the travel plane by exactly a proportional 
amount.  Maybe it would be possible, though, to have a tighter bound on 
SidedPlane.isWithin() than we'd have elsewhere?  Or maybe we could apply an 
alternate, tighter filter in the case of the crossing points in 
GeoComplexPolygon alone.  I'll have to think this through.


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



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

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12096:


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

SOLR-12096: Removing redundant patch file


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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12096:


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

SOLR-12096: Removing redundant patch file


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

[jira] [Commented] (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&focusedCommentId=16430427#comment-16430427
 ] 

Karl Wright commented on LUCENE-8245:
-

Ok, looking at the crossings we get, here's the complete output:

{code}
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-1.4506713533447755, 
lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, 
Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1>  start point travel dist=-0.11274773940907501; end point 
travel dist=3.268072236836579E-13
   [junit4]   1>  start point travel above dist=-0.11274773940806501; end point 
travel above dist=1.336807223683658E-12
   [junit4]   1>  start point travel below dist=-0.11274773941008501; end point 
travel below dist=-6.831927763163422E-13
   [junit4]   1>  start point testpoint dist=-0.34019438500826027; end point 
testpoint dist=0.6525992822450555
   [junit4]   1>  start point testpoint above dist=-0.3401943850072502; end 
point testpoint above dist=0.6525992822460656
   [junit4]   1>  start point testpoint below dist=-0.34019438500927035; end 
point testpoint below dist=0.6525992822440454
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.336807223683658E-12, 
Z=-1.1771178322187736E-11]; edgeplane=0.0; travelInsidePlane=0.0
   [junit4]   1>   Test point inner point [X=0.7540698997149413, 
Y=-0.07411317803504912, Z=-0.6525992822440454]; edgeplane=0.0; 
testPointInsidePlane=0.0
   [junit4]   1>  Edge added 2 to innerCrossingCount
   [junit4]   1>   Test point outer point [X=0.7540698997131706, 
Y=-0.07411317803527853, Z=-0.6525992822460656]; edgeplane=0.0; 
testPointOutsidePlane=0.0
   [junit4]   1>  Edge added 1 to outerCrossingCount
   [junit4]   1>
   [junit4]   1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, 
Z=4.9E-324])] -> [lat=0.13953211802880663, 
lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, 
Z=0.139079795174987])]
   [junit4]   1>  start point travel dist=3.268072236836579E-13; end point 
travel dist=-0.6365576248358092
   [junit4]   1>  start point travel above dist=1.336807223683658E-12; end 
point travel above dist=-0.6365576248347993
   [junit4]   1>  start point travel below dist=-6.831927763163422E-13; end 
point travel below dist=-0.6365576248368193
   [junit4]   1>  start point testpoint dist=0.6525992822450555; end point 
testpoint dist=0.7916790774200425
   [junit4]   1>  start point testpoint above dist=0.6525992822460656; end 
point testpoint above dist=0.7916790774210526
   [junit4]   1>  start point testpoint below dist=0.6525992822440454; end 
point testpoint below dist=0.7916790774190324
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.3368072236836578E-12, 
Z=2.920754816285907E-13]; edgeplane=-5.0487097934144756E-29; 
travelInsidePlane=2.0194839173657902E-28
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, 
Z=-1.4926898632243605E-13]; edgeplane=2.5243548967072378E-29; 
travelOutsidePlane=-1.0097419586828951E-28
   [junit4]   1>  Edge added 1 to outerCrossingCount   
{code}

The travel outer point it incorrectly finds has a distance to each intersecting 
plane that's on the order of 1e-28.  That basically says it's a real 
intersection given the inputs.  So that second edge does intersect the outer 
envelope EVEN THOUGH it doesn't look like it should, based on the endpoint.

The only other thing that can be going wrong is that the edge endpoint's bounds 
are just sloppy enough to permit this intersection to be included in the 
crossings list, while it really should be rejected.  I'll need more diagnostics 
to rule that in or out as the underlying cause, but I'm getting busy at work 
now so that's not going to happen for a while.


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

[jira] [Commented] (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&focusedCommentId=16430421#comment-16430421
 ] 

Ignacio Vera commented on LUCENE-8245:
--

I don't think it either. I will add later today or tomorrow a random test that 
it is extremely good to find all these cases. It can be used to validate 
solutions.

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



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

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

[jira] [Updated] (SOLR-12202) solr-exporter.cmd cannot be run on Windows

[Minoru Osuka (JIRA)]

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

Minoru Osuka updated SOLR-12202:

Priority: Major  (was: Critical)

> solr-exporter.cmd cannot be run on Windows
> --
>
> Key: SOLR-12202
> URL: https://issues.apache.org/jira/browse/SOLR-12202
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Minoru Osuka
>Priority: Major
>
> solr-exporter.cmd could not be run on Windows due to following:
> - incorrect main class name.
> - incorrect classpath specification.



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

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