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

[Policeman Jenkins Server]

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

9 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([B31D5F82D3925E09:E0A41D323183CBF3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:401)
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.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([B31D5F82D3925E09:8A93E6C2FC6D97F7]:0)
at 

[jira] [Commented] (SOLR-11920) Differential file copy for IndexFetcher

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-11920:
-

Thanks for reporting, Steve. I'll look into this.

> Differential file copy for IndexFetcher
> ---
>
> Key: SOLR-11920
> URL: https://issues.apache.org/jira/browse/SOLR-11920
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11920.patch, SOLR-11920.patch, 
> thetaphi.Lucene.Solr.7.x.Linux.1675.log.txt.gz
>
>
> In the case of fullCopy=true, all files are copied over from the 
> leader/master irrespective of whether or not that exact file exists with the 
> replica/slave. This is wasteful, esp. in tlog replicas or pull replicas, when 
> only a fraction of the total files are different.
> This stems from SOLR-11815.



--
This message was sent by Atlassian 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-8251) Test failure, geo3d complex polygons

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-8251.
-
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4
   6.7

> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
> -58.984559858566556,0.0 -3.68E-321,-66.33598777585381 
> -7.382056816201731,135.63207358036593 -51.43541696593334))
> WKT: POINT(0.005183505059185348 1.98E-321)
> normal polygon: false
> large polygon: true
> at 
> 

[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons

[ASF subversion and git services (JIRA)]

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

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

Commit 8613627968024e3f4e3e6e1af8d0af8f90afee94 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=8613627 ]

LUCENE-8251: Add an explicit test case to cover the discovered failure.  But it 
appears to be already fixed.


> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 

[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons

[ASF subversion and git services (JIRA)]

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

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

Commit 21f39627624fe4d2b80ca85fae8fdf2b26fd70b6 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=21f3962 ]

LUCENE-8251: Add an explicit test case to cover the discovered failure.  But it 
appears to be already fixed.


> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
> 

[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons

[ASF subversion and git services (JIRA)]

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

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

Commit f41e7c4da7e5386541c9ad2cf0cf6a98d0d41c54 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=f41e7c4 ]

LUCENE-8251: Add an explicit test case to cover the discovered failure.  But it 
appears to be already fixed.


> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
> 

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[Tapan Vaishnav (JIRA)]

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

Tapan Vaishnav commented on SOLR-11913:
---

I see, how come it didn't show anything in the following report?
https://issues.apache.org/jira/browse/SOLR-11913?focusedCommentId=16428288=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16428288

Also, apologies that you had to most of the work.

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

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

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/198/consoleText

[repro] Revision: 502fd4bf12b8860b8eea504a96ad1b49dd52938c

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestTriggerIntegration 
-Dtests.method=testNodeAddedTrigger -Dtests.seed=93925E63CC51A4B4 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ca-ES -Dtests.timezone=Pacific/Samoa -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestDocTermOrds 
-Dtests.method=testTriggerUnInvertLimit -Dtests.seed=93925E63CC51A4B4 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ro-RO -Dtests.timezone=Asia/Ho_Chi_Minh -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestHdfsCloudBackupRestore 
-Dtests.method=test -Dtests.seed=93925E63CC51A4B4 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=uk-UA -Dtests.timezone=Africa/Asmera -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: 
0014f3af88367961d8a7eb84a1a2333ecf66cb46
[repro] git fetch
[repro] git checkout 502fd4bf12b8860b8eea504a96ad1b49dd52938c

[...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]   TestTriggerIntegration
[repro]   TestDocTermOrds
[repro]   TestHdfsCloudBackupRestore
[repro] ant compile-test

[...truncated 3319 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestTriggerIntegration|*.TestDocTermOrds|*.TestHdfsCloudBackupRestore"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=93925E63CC51A4B4 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ca-ES -Dtests.timezone=Pacific/Samoa -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   0/5 failed: 
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore
[repro]   4/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
[repro]   5/5 failed: org.apache.solr.uninverting.TestDocTermOrds

[repro] Re-testing 100% failures at the tip of branch_7x
[repro] ant clean

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

[...truncated 3319 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestDocTermOrds" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=93925E63CC51A4B4 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ro-RO -Dtests.timezone=Asia/Ho_Chi_Minh -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures at the tip of branch_7x:
[repro]   5/5 failed: org.apache.solr.uninverting.TestDocTermOrds

[repro] Re-testing 100% failures at the tip of branch_7x without a seed
[repro] ant clean

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

[...truncated 3319 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestDocTermOrds" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ro-RO -Dtests.timezone=Asia/Ho_Chi_Minh 

[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8251:
-

I created an explicit test to cover this failure, but it looks like yesterday's 
commit already addressed it.
Will commit the explicit test anyway.


> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
> -58.984559858566556,0.0 -3.68E-321,-66.33598777585381 
> -7.382056816201731,135.63207358036593 -51.43541696593334))
> WKT: POINT(0.005183505059185348 1.98E-321)
> normal polygon: false
> large polygon: true
>  

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11913:
-

Here's another update.  It turns out there were some problems with 
TextResponseWriter's order of instanceof checks.  So I tweaked that order to 
put some of the more general stuff towards the end.  I also added a nice 
toString to the Map.Entry we have.  Hopefully tests pass this time...

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

[jira] [Updated] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11913:

Attachment: SOLR-11913.patch

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons

[ASF subversion and git services (JIRA)]

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

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

Commit edcecb2f42c4cd4b09b13f6bc35828551e86e32f 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=edcecb2 ]

LUCENE-8251: Annotate occasionally failing test with AwaitsFix


> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
> -58.984559858566556,0.0 -3.68E-321,-66.33598777585381 
> 

[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons

[ASF subversion and git services (JIRA)]

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

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

Commit e541ed89f3e2968e0a4497035aaa42614d050e8d 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=e541ed8 ]

LUCENE-8251: Annotate occasionally failing test with AwaitsFix


> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
> -58.984559858566556,0.0 -3.68E-321,-66.33598777585381 
> 

[jira] [Commented] (LUCENE-8251) Test failure, geo3d complex polygons

[ASF subversion and git services (JIRA)]

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

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

Commit e8f1649ab4f5f79cd1dc6b7b4f26c5f6ec133bc5 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=e8f1649 ]

LUCENE-8251: Annotate occasionally failing test with AwaitsFix


> Test failure, geo3d complex polygons
> 
>
> Key: LUCENE-8251
> URL: https://issues.apache.org/jira/browse/LUCENE-8251
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (8.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>Priority: Major
>
> {code}
> Error Message:
>  Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: 
> GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of shapes=1, 
> address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
> lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
> Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
> -51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
> -3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
> -51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
> polygon: false large polygon: true
> Stack Trace:
> java.lang.AssertionError:
> Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
> {planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
> lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
> Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]], internalEdges={0}}]}
> Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
> shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
> lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
> Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
> {[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
> Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
> lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
> Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
> lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
> Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, 
> Y=0.0, Z=-6.4E-323])]}}
> Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
> Y=9.057045181228716E-5, Z=3.5E-323])]
> WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
> -58.984559858566556,0.0 -3.68E-321,-66.33598777585381 
> 

[jira] [Created] (LUCENE-8251) Test failure, geo3d complex polygons

[Karl Wright (JIRA)]

Karl Wright created LUCENE-8251:
---

 Summary: Test failure, geo3d complex polygons
 Key: LUCENE-8251
 URL: https://issues.apache.org/jira/browse/LUCENE-8251
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial3d
Affects Versions: master (8.0)
Reporter: Karl Wright
Assignee: Karl Wright


{code}
Error Message:
 Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: GeoComplexPolygon: 
{planetmodel=PlanetModel.WGS84, number of shapes=1, address=814a2a8c, 
testPoint=[lat=-1.1675693914784415, 
lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
{[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
-51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
-3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
-51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
polygon: false large polygon: true

Stack Trace:
java.lang.AssertionError:
Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]], internalEdges={0}}]}

Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
{[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]}}

Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
Y=9.057045181228716E-5, Z=3.5E-323])]

WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
-58.984559858566556,0.0 -3.68E-321,-66.33598777585381 
-7.382056816201731,135.63207358036593 -51.43541696593334))

WKT: POINT(0.005183505059185348 1.98E-321)
normal polygon: false
large polygon: true

at 
__randomizedtesting.SeedInfo.seed([C1E5FF7FBC7AC980:47CE8D3C5A69DD5B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testComparePolygons(RandomGeoPolygonTest.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 

[jira] [Created] (SOLR-12222) TestDistributedSearch failure: "Expected to find shardAddress in the up shard info"

[JIRA]

Tomás Fernández Löbbe created SOLR-1:


 Summary: TestDistributedSearch failure: "Expected to find 
shardAddress in the up shard info"
 Key: SOLR-1
 URL: https://issues.apache.org/jira/browse/SOLR-1
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Tomás Fernández Löbbe


This is a pretty common failure of this test. Here is an example from a recent 
Jenkins failure
{noformat}
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1630/
Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle 
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException: 
Time allowed to handle this request exceeded  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
  at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
  at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844) ,time=1}

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle 
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException: 
Time allowed to handle this request exceeded
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:844)
{noformat}



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

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testComparePolygons 
{seed=[C1E5FF7FBC7AC980:47CE8D3C5A69DD5B]}

Error Message:
 Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]], internalEdges={0}}]}  Large polygon: GeoComplexPolygon: 
{planetmodel=PlanetModel.WGS84, number of shapes=1, address=814a2a8c, 
testPoint=[lat=-1.1675693914784415, 
lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
{[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]}}  Point: [lat=3.5E-323, 
lon=9.046923007656787E-5([X=1.0011188498955597, Y=9.057045181228716E-5, 
Z=3.5E-323])]  WKT: POLYGON((135.63207358036593 
-51.43541696593334,113.00782694696038 -58.984559858566556,0.0 
-3.68E-321,-66.33598777585381 -7.382056816201731,135.63207358036593 
-51.43541696593334))  WKT: POINT(0.005183505059185348 1.98E-321) normal 
polygon: false large polygon: true 

Stack Trace:
java.lang.AssertionError: 
Standard polygon: GeoCompositePolygon: {[GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])]], internalEdges={2}}, GeoConvexPolygon: 
{planetmodel=PlanetModel.WGS84, points=[[lat=-0.12884119701201008, 
lon=-1.157781399251359([X=0.3984689569776051, Y=-0.9092889699600808, 
Z=-0.1286216320286114])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]], internalEdges={0}}]}

Large polygon: GeoComplexPolygon: {planetmodel=PlanetModel.WGS84, number of 
shapes=1, address=814a2a8c, testPoint=[lat=-1.1675693914784415, 
lon=-1.850615018297906E-4([X=0.39171238223740806, Y=-7.249088256972983E-5, 
Z=-0.9182146655290553])], testPointInSet=true, shapes={ 
{[lat=-0.12884119701201008, lon=-1.157781399251359([X=0.3984689569776051, 
Y=-0.9092889699600808, Z=-0.1286216320286114])], [lat=-0.8977173781916888, 
lon=2.3672262552845993([X=-0.44522608342175374, Y=0.435509619867484, 
Z=-0.7811731004355484])], [lat=-1.0294747773716673, 
lon=1.97235866074843([X=-0.20112459723348416, Y=0.47363995489643546, 
Z=-0.8558716366345036])], [lat=-6.4E-323, lon=0.0([X=1.0011188539924791, Y=0.0, 
Z=-6.4E-323])]}}

Point: [lat=3.5E-323, lon=9.046923007656787E-5([X=1.0011188498955597, 
Y=9.057045181228716E-5, Z=3.5E-323])]

WKT: POLYGON((135.63207358036593 -51.43541696593334,113.00782694696038 
-58.984559858566556,0.0 -3.68E-321,-66.33598777585381 
-7.382056816201731,135.63207358036593 -51.43541696593334))

WKT: POINT(0.005183505059185348 1.98E-321)
normal polygon: false
large polygon: true

at 
__randomizedtesting.SeedInfo.seed([C1E5FF7FBC7AC980:47CE8D3C5A69DD5B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest.testComparePolygons(RandomGeoPolygonTest.java:179)
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 

[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=16436750#comment-16436750
 ] 

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

Commit eedd3cea6504c836a6a5ff9c64602546e3a9ff65 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=eedd3ce ]

LUCENE-8245: Make precommit happy, again.


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

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

Commit 539c7769b2a6ebf605fcdc075d92af4a22979e11 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=539c776 ]

LUCENE-8245: Make precommit happy, again.


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

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

Commit 1d201f3c18ef150132e329bac6bb8ecc3ca8c4e0 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=1d201f3 ]

LUCENE-8245: Make precommit happy, again.


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

[Karl Wright]

I've been having inconsistent runs of precommit.  Sometimes it complains,
sometimes not.  But easily fixed -- I'll push javadoc now.

Karl

On Thu, Apr 12, 2018 at 8:50 PM, Erick Erickson 
wrote:

> I'm getting this precommit failure on a fresh clone of master:
>
> -documentation-lint:
>
>  [echo] checking for broken html...
>
> [jtidy] Checking for broken html (such as invalid tags)...
>
>[delete] Deleting directory
> /Users/Erick/apache/solrVersions/solr-12028/lucene/build/jtidy_tmp
>  [echo] Checking for broken links...
>  [exec]
>  [exec] Crawl/parse...
>  [exec]
>  [exec] Verify...
>  [echo] Checking for missing docs...
>  [exec]
>  [exec] build/docs/spatial3d/org/apache/lucene/spatial3d/geom/
> SidedPlane.html
>  [exec]   missing Methods: strictlyWithin-double-double-double-
>  [exec]   missing Methods:
> strictlyWithin-org.apache.lucene.spatial3d.geom.Vector-
>  [exec]
>  [exec] Missing javadocs were found!
>
> Anyone have a clue? I don't see Jenkins failures for this so maybe
> it's just me somehow.
>
> Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Resolved] (SOLR-12176) Improve FORCELEADER to handle the case when a replica win the election but does not present in clusterstate

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat resolved SOLR-12176.
-
   Resolution: Fixed
Fix Version/s: 7.4

> Improve FORCELEADER to handle the case when a replica win the election but 
> does not present in clusterstate
> ---
>
> Key: SOLR-12176
> URL: https://issues.apache.org/jira/browse/SOLR-12176
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12176.patch
>
>
> There can be the case when a replica wins the election but it does not 
> present in clusterstate. Maybe when the Overseer sent the UNLOAD request to 
> the LEADER (in DeleteReplicaCmd), it met some exception (therefore the 
> request never reach the LEADER), the Overseer it that case will forcefully 
> remove the LEADER from clusterstate. 
> If a shard reaches that case, users will only see a leaderless shard and call 
> FORCELEADER won't be able to solve their problem. Therefore FORCELEADER 
> should be more robust, to handle such cases.



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

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

Re: Precommit failures

[Shawn Heisey]

On 4/12/2018 8:56 PM, David Smiley wrote:
It's happening to me too!  I added a /** anything */ comment on these 
two methods and the warning went away.  But we don't have rules about 
requiring comments on public methods (I thought)?


I thought the point of the javadoc check was to make sure that all 
public methods *do* have javadocs, unless they're overriding a method in 
a parent class/interface that already has javadoc.  (IDEs will display 
the parent javadoc in those cases)


I find it frustrating when I'm using a public API in a library and it's 
not documented to show how it can be used.  While it's true that good 
choices for all the class/method/parameter names can sometimes make the 
exposed API self-documenting, often the usage is just too complex for 
that, or has gotchas that require explanation.


Probably a good idea for all public fields to have javadoc as well, but 
I wouldn't expect that to be a requirement.If javadoc on "protected" 
items is published, then I think those should require javadoc too, so 
someone extending the class will know what those things do.


Thanks,
Shawn


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

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[Tapan Vaishnav (JIRA)]

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

Tapan Vaishnav commented on SOLR-11913:
---

bq.Sure; I'll re-order that. There is no real code rule about that here; I just 
try to maintain some semblance of some sort of organization that feels 
reasonable and not haphazard.
I see. 
bq.Thanks for helping out. I'll expect to commit soon after the tests pass.
(y)

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

Re: Precommit failures

[David Smiley]

It's happening to me too!  I added a /** anything */ comment on these two
methods and the warning went away.  But we don't have rules about requiring
comments on public methods (I thought)?

On Thu, Apr 12, 2018 at 8:51 PM Erick Erickson 
wrote:

> I'm getting this precommit failure on a fresh clone of master:
>
> -documentation-lint:
>
>  [echo] checking for broken html...
>
> [jtidy] Checking for broken html (such as invalid tags)...
>
>[delete] Deleting directory
> /Users/Erick/apache/solrVersions/solr-12028/lucene/build/jtidy_tmp
>  [echo] Checking for broken links...
>  [exec]
>  [exec] Crawl/parse...
>  [exec]
>  [exec] Verify...
>  [echo] Checking for missing docs...
>  [exec]
>  [exec]
> build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html
>  [exec]   missing Methods: strictlyWithin-double-double-double-
>  [exec]   missing Methods:
> strictlyWithin-org.apache.lucene.spatial3d.geom.Vector-
>  [exec]
>  [exec] Missing javadocs were found!
>
> Anyone have a clue? I don't see Jenkins failures for this so maybe
> it's just me somehow.
>
> Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11913:
-

{quote}We are not using the _Override_ annotation for the stream function, so 
isn't it better to re-order it about the iterator function for better code 
style?
{quote}
Sure; I'll re-order that.  There is no real code rule about that here; I just 
try to maintain some semblance of some sort of organization that feels 
reasonable and not haphazard.

Thanks for helping out.  I'll expect to commit soon after the tests pass.

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

[jira] [Updated] (SOLR-12221) Add valueAt Stream Evaluator

[Joel Bernstein (JIRA)]

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

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

> Add valueAt Stream Evaluator
> 
>
> Key: SOLR-12221
> URL: https://issues.apache.org/jira/browse/SOLR-12221
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12221.patch
>
>
> The *valueAt* Stream Evaluator returns the value at a specific index of an 
> array or the value of a specific row and column of a matrix.
> Sample syntax for an array:
> {code:java}
> let(a=array(1, 2, 3),
> b=valueAt(a, 2)){code}



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

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

[jira] [Updated] (SOLR-12221) Add valueAt Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12221:
--
Description: 
The *valueAt* Stream Evaluator returns the value at a specific index of an 
array or the value of a specific row and column of a matrix.

Sample syntax for an array:
{code:java}
let(a=array(1, 2, 3),
b=valueAt(a, 2)){code}

  was:
The *valueAt* Stream Evaluator returns the value at a specific index of an 
array or the value of a specific row and column of a matrix.

Sample syntax for an array:
{code:java}
let(a=array(1,2,3),
b=valueAt(2)){code}


> Add valueAt Stream Evaluator
> 
>
> Key: SOLR-12221
> URL: https://issues.apache.org/jira/browse/SOLR-12221
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
>
> The *valueAt* Stream Evaluator returns the value at a specific index of an 
> array or the value of a specific row and column of a matrix.
> Sample syntax for an array:
> {code:java}
> let(a=array(1, 2, 3),
> b=valueAt(a, 2)){code}



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

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

[jira] [Updated] (SOLR-12221) Add valueAt Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12221:
--
Fix Version/s: 7.4

> Add valueAt Stream Evaluator
> 
>
> Key: SOLR-12221
> URL: https://issues.apache.org/jira/browse/SOLR-12221
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
>
> The valuaAt Stream Evaluator returns the value at a specific index of an 
> array or the value of a specific row and column of a matrix.
> Sample syntax for an array:
> {code:java}
> let(a=array(1,2,3),
> b=valueAt(2)){code}



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

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

[jira] [Assigned] (SOLR-12221) Add valueAt Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-12221:
-

Assignee: Joel Bernstein

> Add valueAt Stream Evaluator
> 
>
> Key: SOLR-12221
> URL: https://issues.apache.org/jira/browse/SOLR-12221
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
>
> The valuaAt Stream Evaluator returns the value at a specific index of an 
> array or the value of a specific row and column of a matrix.
> Sample syntax for an array:
> {code:java}
> let(a=array(1,2,3),
> b=valueAt(2)){code}



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

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

[jira] [Updated] (SOLR-12221) Add valueAt Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12221:
--
Description: 
The *valueAt* Stream Evaluator returns the value at a specific index of an 
array or the value of a specific row and column of a matrix.

Sample syntax for an array:
{code:java}
let(a=array(1,2,3),
b=valueAt(2)){code}

  was:
The valuaAt Stream Evaluator returns the value at a specific index of an array 
or the value of a specific row and column of a matrix.

Sample syntax for an array:
{code:java}
let(a=array(1,2,3),
b=valueAt(2)){code}


> Add valueAt Stream Evaluator
> 
>
> Key: SOLR-12221
> URL: https://issues.apache.org/jira/browse/SOLR-12221
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
>
> The *valueAt* Stream Evaluator returns the value at a specific index of an 
> array or the value of a specific row and column of a matrix.
> Sample syntax for an array:
> {code:java}
> let(a=array(1,2,3),
> b=valueAt(2)){code}



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

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

[jira] [Created] (SOLR-12221) Add valueAt Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-12221:
-

 Summary: Add valueAt Stream Evaluator
 Key: SOLR-12221
 URL: https://issues.apache.org/jira/browse/SOLR-12221
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The valuaAt Stream Evaluator returns the value at a specific index of an array 
or the value of a specific row and column of a matrix.

Sample syntax for an array:
{code:java}
let(a=array(1,2,3),
b=valueAt(2)){code}



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

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

[jira] [Commented] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8248:


| (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 5 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  0m  
7s{color} | {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  0m  
7s{color} | {color:red} test-framework in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  0m  
7s{color} | {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  0m  
8s{color} | {color:red} test-framework in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m  7s{color} 
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m  7s{color} 
| {color:red} test-framework in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m  7s{color} 
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m  8s{color} 
| {color:red} test-framework in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}  
0m  7s{color} | {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}  
0m  7s{color} | {color:red} test-framework in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}  
0m  7s{color} | {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}  
0m  8s{color} | {color:red} test-framework in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Check forbidden APIs {color} | {color:red} 
 0m  7s{color} | {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} | 
{color:red}  0m  7s{color} | {color:red} core in the patch failed. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m  6s{color} 
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m  7s{color} 
| {color:red} test-framework in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m  7s{color} 
| {color:red} core in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m  8s{color} 
| {color:red} test-framework in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  2m 39s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8248 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12918825/LUCENE-8248.2.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 0014f3a |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_152 |
| compile | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/11/artifact/out/patch-compile-lucene_core.txt
 |
| compile | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/11/artifact/out/patch-compile-lucene_test-framework.txt
 |
| compile | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/11/artifact/out/patch-compile-solr_core.txt
 |
| compile | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/11/artifact/out/patch-compile-solr_test-framework.txt
 |
| javac | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/11/artifact/out/patch-compile-lucene_core.txt
 |
| javac | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/11/artifact/out/patch-compile-lucene_test-framework.txt
 |
| javac | 

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 36 - Failure

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeMarkersRegistration

Error Message:
Path /autoscaling/nodeAdded/127.0.0.1:10003_solr should have been deleted

Stack Trace:
java.lang.AssertionError: Path /autoscaling/nodeAdded/127.0.0.1:10003_solr 
should have been deleted
at 
__randomizedtesting.SeedInfo.seed([1A9C1F6766EFEF73:226976B68DA229C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeMarkersRegistration(TestTriggerIntegration.java:860)
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.cloud.autoscaling.sim.TestTriggerIntegration.testSearchRate

Error Message:
The trigger did not fire at all

Stack 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressUpdateSameID

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:904)
at org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:1243)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:327)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressUpdateSameID(TestIndexingSequenceNumbers.java:126)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(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)
Caused by: java.lang.AssertionError: docValues generation is still uninitialized
at __randomizedtesting.SeedInfo.seed([C72B4F1A7F72AC53]:0)
at 
org.apache.lucene.index.PendingSoftDeletes.onDocValuesUpdate(PendingSoftDeletes.java:123)
at 
org.apache.lucene.index.ReadersAndUpdates.handleNumericDVUpdates(ReadersAndUpdates.java:347)
at 
org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:652)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.release(IndexWriter.java:619)
at 

[jira] [Commented] (SOLR-12219) Autoscaling trigger to forceleader

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12219:
-

Would that force just be an election, or would it be forcing a specific replica 
to the leader role?

If it's an election, does that tend to pick the system with the most recent 
changes?

The best option is to not ever get into a situation where there's no leader.  
If we have documented situations where that happens, can we make changes to 
keep it from happening in those situations?


> Autoscaling trigger to forceleader
> --
>
> Key: SOLR-12219
> URL: https://issues.apache.org/jira/browse/SOLR-12219
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Priority: Major
>
> In a scenario where a shard doesn't have a leader for an extended period of 
> time, it would be nice if we can configure a trigger to fire a FORCELEADER 
> API call
>  
> FORCELEADER is the first step an ops person would fire today to come out of 
> the leaderless shard scenario and if this could be automated then it would be 
> useful for teams
>  
>  



--
This message was sent by Atlassian 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-12220) TestReplicationHandle.doTestStressReplication() fails on Windows because an index directory can't be deleted

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12220:
---

Maybe we could ignore the non-deleteable directory on Windows?

> TestReplicationHandle.doTestStressReplication() fails on Windows because an 
> index directory can't be deleted
> 
>
> Key: SOLR-12220
> URL: https://issues.apache.org/jira/browse/SOLR-12220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Priority: Major
> Attachments: thetaphi.Lucene.Solr.7.x.Windows.533.log.txt.gz
>
>
> Several recent Jenkins failures, e.g. 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/533/]:
> {noformat}
>[junit4]   2> 1820871 ERROR (qtp574829981-16047) [x:collection1] 
> o.a.s.c.CachingDirectoryFactory Error removing directory 
> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440
>  before 
> core close:java.io.IOException: Unable to delete file: 
> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440\_0_Lucene50_0.tim
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
>[junit4]   2>at 
> org.apache.solr.core.StandardDirectoryFactory.removeDirectory(StandardDirectoryFactory.java:108)
>[junit4]   2>at 
> org.apache.solr.core.CachingDirectoryFactory.closeCacheValue(CachingDirectoryFactory.java:274)
>[junit4]   2>at 
> org.apache.solr.core.CachingDirectoryFactory.release(CachingDirectoryFactory.java:437)
>[junit4]   2>at 
> org.apache.solr.search.SolrIndexSearcher.close(SolrIndexSearcher.java:496)
>[junit4]   2>at 
> org.apache.solr.core.SolrCore$2.close(SolrCore.java:2402)
>[junit4]   2>at 
> org.apache.solr.util.RefCounted.decref(RefCounted.java:56)
>[junit4]   2>at 
> org.apache.solr.request.SolrQueryRequestBase.close(SolrQueryRequestBase.java:154)
>[junit4]   2>at 
> org.apache.solr.servlet.HttpSolrCall.destroy(HttpSolrCall.java:566)
>[junit4]   2>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:411)
>[junit4]   2>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:339)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>[junit4]   2>at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>[junit4]   2>at 
> org.eclipse.jetty.server.Server.handle(Server.java:530)
>[junit4]   2>at 
> 

[jira] [Updated] (SOLR-12220) TestReplicationHandle.doTestStressReplication() fails on Windows because an index directory can't be deleted

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-12220:
--
Attachment: thetaphi.Lucene.Solr.7.x.Windows.533.log.txt.gz

> TestReplicationHandle.doTestStressReplication() fails on Windows because an 
> index directory can't be deleted
> 
>
> Key: SOLR-12220
> URL: https://issues.apache.org/jira/browse/SOLR-12220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Priority: Major
> Attachments: thetaphi.Lucene.Solr.7.x.Windows.533.log.txt.gz
>
>
> Several recent Jenkins failures, e.g. 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/533/]:
> {noformat}
>[junit4]   2> 1820871 ERROR (qtp574829981-16047) [x:collection1] 
> o.a.s.c.CachingDirectoryFactory Error removing directory 
> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440
>  before 
> core close:java.io.IOException: Unable to delete file: 
> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440\_0_Lucene50_0.tim
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
>[junit4]   2>at 
> org.apache.solr.core.StandardDirectoryFactory.removeDirectory(StandardDirectoryFactory.java:108)
>[junit4]   2>at 
> org.apache.solr.core.CachingDirectoryFactory.closeCacheValue(CachingDirectoryFactory.java:274)
>[junit4]   2>at 
> org.apache.solr.core.CachingDirectoryFactory.release(CachingDirectoryFactory.java:437)
>[junit4]   2>at 
> org.apache.solr.search.SolrIndexSearcher.close(SolrIndexSearcher.java:496)
>[junit4]   2>at 
> org.apache.solr.core.SolrCore$2.close(SolrCore.java:2402)
>[junit4]   2>at 
> org.apache.solr.util.RefCounted.decref(RefCounted.java:56)
>[junit4]   2>at 
> org.apache.solr.request.SolrQueryRequestBase.close(SolrQueryRequestBase.java:154)
>[junit4]   2>at 
> org.apache.solr.servlet.HttpSolrCall.destroy(HttpSolrCall.java:566)
>[junit4]   2>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:411)
>[junit4]   2>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:339)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>[junit4]   2>at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>[junit4]   2>at 
> org.eclipse.jetty.server.Server.handle(Server.java:530)
>[junit4]   2>at 
> 

[jira] [Updated] (SOLR-12220) TestReplicationHandle.doTestStressReplication() fails on Windows because an index directory can't be deleted

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-12220:
--
Summary: TestReplicationHandle.doTestStressReplication() fails on Windows 
because an index directory can't be deleted  (was: 
TestReplicationHandle.doStressTestReplication() fails on Windows because an 
index directory can't be deleted)

> TestReplicationHandle.doTestStressReplication() fails on Windows because an 
> index directory can't be deleted
> 
>
> Key: SOLR-12220
> URL: https://issues.apache.org/jira/browse/SOLR-12220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: Several recent Jenkins failures, e.g. 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/533/]:
> {noformat}
>[junit4]   2> 1820871 ERROR (qtp574829981-16047) [x:collection1] 
> o.a.s.c.CachingDirectoryFactory Error removing directory 
> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440
>  before 
> core close:java.io.IOException: Unable to delete file: 
> C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440\_0_Lucene50_0.tim
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
>[junit4]   2>at 
> org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
>[junit4]   2>at 
> org.apache.solr.core.StandardDirectoryFactory.removeDirectory(StandardDirectoryFactory.java:108)
>[junit4]   2>at 
> org.apache.solr.core.CachingDirectoryFactory.closeCacheValue(CachingDirectoryFactory.java:274)
>[junit4]   2>at 
> org.apache.solr.core.CachingDirectoryFactory.release(CachingDirectoryFactory.java:437)
>[junit4]   2>at 
> org.apache.solr.search.SolrIndexSearcher.close(SolrIndexSearcher.java:496)
>[junit4]   2>at 
> org.apache.solr.core.SolrCore$2.close(SolrCore.java:2402)
>[junit4]   2>at 
> org.apache.solr.util.RefCounted.decref(RefCounted.java:56)
>[junit4]   2>at 
> org.apache.solr.request.SolrQueryRequestBase.close(SolrQueryRequestBase.java:154)
>[junit4]   2>at 
> org.apache.solr.servlet.HttpSolrCall.destroy(HttpSolrCall.java:566)
>[junit4]   2>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:411)
>[junit4]   2>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:339)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>[junit4]   2>at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>[junit4]   2>at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
>[junit4]   2>at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>[junit4]   2>at 
> org.eclipse.jetty.server.Server.handle(Server.java:530)
>[junit4]   

[jira] [Created] (SOLR-12220) TestReplicationHandle.doStressTestReplication() fails on Windows because an index directory can't be deleted

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-12220:
-

 Summary: TestReplicationHandle.doStressTestReplication() fails on 
Windows because an index directory can't be deleted
 Key: SOLR-12220
 URL: https://issues.apache.org/jira/browse/SOLR-12220
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
 Environment: Several recent Jenkins failures, e.g. 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/533/]:

{noformat}
   [junit4]   2> 1820871 ERROR (qtp574829981-16047) [x:collection1] 
o.a.s.c.CachingDirectoryFactory Error removing directory 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440
 before 
core close:java.io.IOException: Unable to delete file: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440\_0_Lucene50_0.tim
   [junit4]   2>at 
org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
   [junit4]   2>at 
org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
   [junit4]   2>at 
org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
   [junit4]   2>at 
org.apache.solr.core.StandardDirectoryFactory.removeDirectory(StandardDirectoryFactory.java:108)
   [junit4]   2>at 
org.apache.solr.core.CachingDirectoryFactory.closeCacheValue(CachingDirectoryFactory.java:274)
   [junit4]   2>at 
org.apache.solr.core.CachingDirectoryFactory.release(CachingDirectoryFactory.java:437)
   [junit4]   2>at 
org.apache.solr.search.SolrIndexSearcher.close(SolrIndexSearcher.java:496)
   [junit4]   2>at 
org.apache.solr.core.SolrCore$2.close(SolrCore.java:2402)
   [junit4]   2>at 
org.apache.solr.util.RefCounted.decref(RefCounted.java:56)
   [junit4]   2>at 
org.apache.solr.request.SolrQueryRequestBase.close(SolrQueryRequestBase.java:154)
   [junit4]   2>at 
org.apache.solr.servlet.HttpSolrCall.destroy(HttpSolrCall.java:566)
   [junit4]   2>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:411)
   [junit4]   2>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:339)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
   [junit4]   2>at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
   [junit4]   2>at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
   [junit4]   2>at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
   [junit4]   2>at 
org.eclipse.jetty.server.Server.handle(Server.java:530)
   [junit4]   2>at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
   [junit4]   2>at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
   [junit4]   2>at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
   [junit4]   2>at 
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
   [junit4]   2>at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
   [junit4]   2>at 

[jira] [Updated] (SOLR-12220) TestReplicationHandle.doTestStressReplication() fails on Windows because an index directory can't be deleted

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-12220:
--
Description: 
Several recent Jenkins failures, e.g. 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/533/]:

{noformat}
   [junit4]   2> 1820871 ERROR (qtp574829981-16047) [x:collection1] 
o.a.s.c.CachingDirectoryFactory Error removing directory 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440
 before 
core close:java.io.IOException: Unable to delete file: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440\_0_Lucene50_0.tim
   [junit4]   2>at 
org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
   [junit4]   2>at 
org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
   [junit4]   2>at 
org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
   [junit4]   2>at 
org.apache.solr.core.StandardDirectoryFactory.removeDirectory(StandardDirectoryFactory.java:108)
   [junit4]   2>at 
org.apache.solr.core.CachingDirectoryFactory.closeCacheValue(CachingDirectoryFactory.java:274)
   [junit4]   2>at 
org.apache.solr.core.CachingDirectoryFactory.release(CachingDirectoryFactory.java:437)
   [junit4]   2>at 
org.apache.solr.search.SolrIndexSearcher.close(SolrIndexSearcher.java:496)
   [junit4]   2>at 
org.apache.solr.core.SolrCore$2.close(SolrCore.java:2402)
   [junit4]   2>at 
org.apache.solr.util.RefCounted.decref(RefCounted.java:56)
   [junit4]   2>at 
org.apache.solr.request.SolrQueryRequestBase.close(SolrQueryRequestBase.java:154)
   [junit4]   2>at 
org.apache.solr.servlet.HttpSolrCall.destroy(HttpSolrCall.java:566)
   [junit4]   2>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:411)
   [junit4]   2>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:339)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
   [junit4]   2>at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
   [junit4]   2>at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
   [junit4]   2>at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
   [junit4]   2>at 
org.eclipse.jetty.server.Server.handle(Server.java:530)
   [junit4]   2>at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
   [junit4]   2>at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
   [junit4]   2>at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
   [junit4]   2>at 
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
   [junit4]   2>at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
   [junit4]   2>at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
   [junit4]   2>at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
   [junit4]   2>at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
   

[jira] [Updated] (SOLR-12220) TestReplicationHandle.doTestStressReplication() fails on Windows because an index directory can't be deleted

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-12220:
--
Environment: (was: Several recent Jenkins failures, e.g. 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/533/]:

{noformat}
   [junit4]   2> 1820871 ERROR (qtp574829981-16047) [x:collection1] 
o.a.s.c.CachingDirectoryFactory Error removing directory 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440
 before 
core close:java.io.IOException: Unable to delete file: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationHandler_A86A8FEB7F34064-001\solr-instance-028\collection1\data\index.20180408092515440\_0_Lucene50_0.tim
   [junit4]   2>at 
org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
   [junit4]   2>at 
org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
   [junit4]   2>at 
org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
   [junit4]   2>at 
org.apache.solr.core.StandardDirectoryFactory.removeDirectory(StandardDirectoryFactory.java:108)
   [junit4]   2>at 
org.apache.solr.core.CachingDirectoryFactory.closeCacheValue(CachingDirectoryFactory.java:274)
   [junit4]   2>at 
org.apache.solr.core.CachingDirectoryFactory.release(CachingDirectoryFactory.java:437)
   [junit4]   2>at 
org.apache.solr.search.SolrIndexSearcher.close(SolrIndexSearcher.java:496)
   [junit4]   2>at 
org.apache.solr.core.SolrCore$2.close(SolrCore.java:2402)
   [junit4]   2>at 
org.apache.solr.util.RefCounted.decref(RefCounted.java:56)
   [junit4]   2>at 
org.apache.solr.request.SolrQueryRequestBase.close(SolrQueryRequestBase.java:154)
   [junit4]   2>at 
org.apache.solr.servlet.HttpSolrCall.destroy(HttpSolrCall.java:566)
   [junit4]   2>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:411)
   [junit4]   2>at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:339)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
   [junit4]   2>at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
   [junit4]   2>at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
   [junit4]   2>at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
   [junit4]   2>at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:527)
   [junit4]   2>at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
   [junit4]   2>at 
org.eclipse.jetty.server.Server.handle(Server.java:530)
   [junit4]   2>at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
   [junit4]   2>at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
   [junit4]   2>at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
   [junit4]   2>at 
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
   [junit4]   2>at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
   [junit4]   2>at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
   [junit4]   2>at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
   [junit4]   2>at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
 

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8231:
-

+1 to commit the latest patch. Thanks for all the work here.

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

[jira] [Commented] (SOLR-11920) Differential file copy for IndexFetcher

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11920:
---

Two other recent Jenkins failures with the same pattern as ^^: 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21793/] and 
[https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1526/]

> Differential file copy for IndexFetcher
> ---
>
> Key: SOLR-11920
> URL: https://issues.apache.org/jira/browse/SOLR-11920
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11920.patch, SOLR-11920.patch, 
> thetaphi.Lucene.Solr.7.x.Linux.1675.log.txt.gz
>
>
> In the case of fullCopy=true, all files are copied over from the 
> leader/master irrespective of whether or not that exact file exists with the 
> replica/slave. This is wasteful, esp. in tlog replicas or pull replicas, when 
> only a fraction of the total files are different.
> This stems from SOLR-11815.



--
This message was sent by Atlassian 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-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit a27d866cde625ccec2ae71d0115a59293257f1ae in lucene-solr's branch 
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a27d866 ]

SOLR-12028: BadApple and AwaitsFix annotations usage


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028-3-Mar.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian 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-12028) BadApple and AwaitsFix annotations usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


Commit 0014f3af88367961d8a7eb84a1a2333ecf66cb46 in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0014f3a ]

SOLR-12028: BadApple and AwaitsFix annotations usage


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028-3-Mar.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



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

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

[jira] [Commented] (SOLR-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11724:
--

Hi Amrit,

Thanks for working on the patch! I like the solution here , seems like the 
right way to solve the problem.

Here's some feedback on the patch:
 # In CdcrReplicatorManager#sendRequestRecoveryToFollowers , the following line 
looks dangerous ( 
[https://docs.oracle.com/javase/7/docs/api/java/util/Map.html#values()] )
 ## 
{code:java}
replicas.remove(slice.getLeader());{code}

 ## Maybe we could add something like this in the inner for loop instead?
{code:java}
if (slice.getLeader().getCoreName().equals(replica.getCoreName())) {
  continue;
}{code}

 ## Do we really need a separate test for this? Maybe in one of the existing 
tests we could increase the target replicationFactor ?
 ## To assert doc counts , we have CdcrTestsUtil#waitForCoresToSync . How about 
something like this instead?
{code:java}
protected static boolean assertShardInSync(String collection, String shard, 
CloudSolrClient client) throws IOException, SolrServerException {
  TimeOut waitTimeOut = new TimeOut(30, TimeUnit.SECONDS, TimeSource.NANO_TIME);
  DocCollection docCollection = 
client.getZkStateReader().getClusterState().getCollection(collection);
  Slice correctSlice = null;
  for (Slice slice : docCollection.getSlices()) {
if (shard.equals(slice.getName())) {
  correctSlice = slice;
  break;
}
  }
  assertNotNull(correctSlice);

  long leaderDocCount;
  try (HttpSolrClient leaderClient = new 
HttpSolrClient.Builder(correctSlice.getLeader().getCoreUrl()).withHttpClient(client.getHttpClient()).build())
 {
leaderDocCount = leaderClient.query(new 
SolrQuery("*:*").setParam("distrib", "false")).getResults().getNumFound();
  }

  while (!waitTimeOut.hasTimedOut()) {
int replicasInSync = 0;
for (Replica replica : correctSlice.getReplicas()) {
  try (HttpSolrClient leaderClient = new 
HttpSolrClient.Builder(replica.getCoreUrl()).withHttpClient(client.getHttpClient()).build())
 {
long replicaDocCount = leaderClient.query(new 
SolrQuery("*:*").setParam("distrib", "false")).getResults().getNumFound();
if (replicaDocCount == leaderDocCount) replicasInSync++;
  }
}
if (replicasInSync == correctSlice.getReplicas().size()) {
  return true;
}
  }
  return false;
}{code}

> Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
> -
>
> Key: SOLR-11724
> URL: https://issues.apache.org/jira/browse/SOLR-11724
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.1
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, 
> SOLR-11724.patch, SOLR-11724.patch
>
>
> Please find the discussion on:
> http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html
> If we index significant documents in to Source, stop indexing and then start 
> CDCR; bootstrapping only copies the index to leader node of shards of the 
> collection, and followers never receive the documents / index until and 
> unless atleast one document is inserted again on source; which propels to 
> target and target collection trigger index replication to followers.
> This behavior needs to be addressed in proper manner, either at target 
> collection or while bootstrapping.



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

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

Precommit failures

[Erick Erickson]

I'm getting this precommit failure on a fresh clone of master:

-documentation-lint:

 [echo] checking for broken html...

[jtidy] Checking for broken html (such as invalid tags)...

   [delete] Deleting directory
/Users/Erick/apache/solrVersions/solr-12028/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec]
 [exec] Crawl/parse...
 [exec]
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec]
 [exec] 
build/docs/spatial3d/org/apache/lucene/spatial3d/geom/SidedPlane.html
 [exec]   missing Methods: strictlyWithin-double-double-double-
 [exec]   missing Methods:
strictlyWithin-org.apache.lucene.spatial3d.geom.Vector-
 [exec]
 [exec] Missing javadocs were found!

Anyone have a clue? I don't see Jenkins failures for this so maybe
it's just me somehow.

Erick

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

[jira] [Commented] (SOLR-12219) Autoscaling trigger to forceleader

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12219:
--

You would need to explicitly create a trigger using an API .  A user would 
explicitly configure this . 

Not sure if the syntax is correct but one would setup something like this with 
autoscaling:
{code:java}
"set-trigger": {
  "name" : "leaderless_shard_trigger",
  "event" : "leaderLost",
  "waitFor" : "300s",
  "enabled" : true,
  "actions" : [
   {
"name" : "compute_plan",
"class": "solr.ComputePlanAction"
   },
   {
"name" : "execute_plan",
"class": "solr.ExecutePlanAction"
   }
  ]
 }
}{code}

> Autoscaling trigger to forceleader
> --
>
> Key: SOLR-12219
> URL: https://issues.apache.org/jira/browse/SOLR-12219
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Priority: Major
>
> In a scenario where a shard doesn't have a leader for an extended period of 
> time, it would be nice if we can configure a trigger to fire a FORCELEADER 
> API call
>  
> FORCELEADER is the first step an ops person would fire today to come out of 
> the leaderless shard scenario and if this could be automated then it would be 
> useful for teams
>  
>  



--
This message was sent by Atlassian 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-11920) Differential file copy for IndexFetcher

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11920 at 4/13/18 12:38 AM:
-

{{TestReplicationHandler.doTestStressReplication()}} has failed recently on 
Jenkins in new code committed under this issue - hard linking fails AFAICT 
because the source file can't be found, e.g. from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1675/] - I'll attach the 
full log:

{noformat}
   [junit4]   2> 756661 INFO  (explicit-fetchindex-cmd) [] 
o.a.s.h.IndexFetcher Starting download (fullCopy=true) to 
MockDirectoryWrapper(NIOFSDirectory@/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/index-NIOFSDirectory-040
 lockFactory=org.a
pache.lucene.store.NativeFSLockFactory@cd4307)
   [junit4]   2> 756661 INFO  (explicit-fetchindex-cmd) [] 
o.a.s.h.IndexFetcher Don't need to download this file. Local file's path is: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/solr-instance-017/./collection1/data/index.2018040903324047
5/_0.si, checksum is: 4156999003
   [junit4]   2> 756662 ERROR (explicit-fetchindex-cmd) [] 
o.a.s.h.ReplicationHandler Index fetch failed 
:org.apache.solr.common.SolrException: Index fetch failed : 
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:699)
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:369)
   [junit4]   2>at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:420)
   [junit4]   2>at 
org.apache.solr.handler.ReplicationHandler.lambda$handleRequestBody$0(ReplicationHandler.java:298)
   [junit4]   2>at java.lang.Thread.run(Thread.java:748)
   [junit4]   2> Caused by: java.nio.file.NoSuchFileException: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/solr-instance-017/./collection1/data/index.20180409033240691/_0.si
 -> /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core
/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/solr-instance-017/./collection1/data/index.20180409033240475/_0.si
   [junit4]   2>at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
   [junit4]   2>at 
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
   [junit4]   2>at 
sun.nio.fs.UnixFileSystemProvider.createLink(UnixFileSystemProvider.java:476)
   [junit4]   2>at java.nio.file.Files.createLink(Files.java:1086)
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.downloadIndexFiles(IndexFetcher.java:1046)
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:592)
   [junit4]   2>... 4 more
[...]
   [junit4]   2> 786815 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[9FAEE8E64FDC4AB6]) [ 
   ] o.a.s.h.TestReplicationHandler Waiting for 162 docs
   [junit4]   2> 786915 INFO  (qtp18488161-9808) [x:collection1] 
o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
params={q=*:*=id+desc=javabin=2} hits=107 status=0 QTime=0
   [junit4]   2> 786915 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[9FAEE8E64FDC4AB6]) [ 
   ] o.a.s.h.TestReplicationHandler Waited for 3ms and found 107 docs
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestReplicationHandler -Dtests.method=doTestStressReplication 
-Dtests.seed=9FAEE8E64FDC4AB6 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=et-EE -Dtests.timezone=Africa/Tripoli -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 31.0s J1 | TestReplicationHandler.doTestStressReplication 
<<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<162> but 
was:<107>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([9FAEE8E64FDC4AB6:4405E8204AF42305]:0)
   [junit4]>at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:904)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}


was (Author: steve_rowe):
{{TestReplicationHandler.testStressReplication()}} has failed recently on 
Jenkins in new code committed under this issue - hard linking fails AFAICT 
because the source file can't be found, e.g. from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1675/] - I'll attach the 
full log:

{noformat}
   [junit4]   2> 756661 INFO  (explicit-fetchindex-cmd) [] 
o.a.s.h.IndexFetcher Starting download (fullCopy=true) to 

[jira] [Updated] (SOLR-11920) Differential file copy for IndexFetcher

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11920:
--
Attachment: thetaphi.Lucene.Solr.7.x.Linux.1675.log.txt.gz

> Differential file copy for IndexFetcher
> ---
>
> Key: SOLR-11920
> URL: https://issues.apache.org/jira/browse/SOLR-11920
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11920.patch, SOLR-11920.patch, 
> thetaphi.Lucene.Solr.7.x.Linux.1675.log.txt.gz
>
>
> In the case of fullCopy=true, all files are copied over from the 
> leader/master irrespective of whether or not that exact file exists with the 
> replica/slave. This is wasteful, esp. in tlog replicas or pull replicas, when 
> only a fraction of the total files are different.
> This stems from SOLR-11815.



--
This message was sent by Atlassian 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-11920) Differential file copy for IndexFetcher

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11920:
--
Attachment: (was: 
apache.Lucene.Solr.NightlyTests.master.1526.log.txt.gz)

> Differential file copy for IndexFetcher
> ---
>
> Key: SOLR-11920
> URL: https://issues.apache.org/jira/browse/SOLR-11920
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11920.patch, SOLR-11920.patch
>
>
> In the case of fullCopy=true, all files are copied over from the 
> leader/master irrespective of whether or not that exact file exists with the 
> replica/slave. This is wasteful, esp. in tlog replicas or pull replicas, when 
> only a fraction of the total files are different.
> This stems from SOLR-11815.



--
This message was sent by Atlassian 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-11920) Differential file copy for IndexFetcher

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-11920:
---

{{TestReplicationHandler.testStressReplication()}} has failed recently on 
Jenkins in new code committed under this issue - hard linking fails AFAICT 
because the source file can't be found, e.g. from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1675/] - I'll attach the 
full log:

{noformat}
   [junit4]   2> 756661 INFO  (explicit-fetchindex-cmd) [] 
o.a.s.h.IndexFetcher Starting download (fullCopy=true) to 
MockDirectoryWrapper(NIOFSDirectory@/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/index-NIOFSDirectory-040
 lockFactory=org.a
pache.lucene.store.NativeFSLockFactory@cd4307)
   [junit4]   2> 756661 INFO  (explicit-fetchindex-cmd) [] 
o.a.s.h.IndexFetcher Don't need to download this file. Local file's path is: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/solr-instance-017/./collection1/data/index.2018040903324047
5/_0.si, checksum is: 4156999003
   [junit4]   2> 756662 ERROR (explicit-fetchindex-cmd) [] 
o.a.s.h.ReplicationHandler Index fetch failed 
:org.apache.solr.common.SolrException: Index fetch failed : 
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:699)
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:369)
   [junit4]   2>at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:420)
   [junit4]   2>at 
org.apache.solr.handler.ReplicationHandler.lambda$handleRequestBody$0(ReplicationHandler.java:298)
   [junit4]   2>at java.lang.Thread.run(Thread.java:748)
   [junit4]   2> Caused by: java.nio.file.NoSuchFileException: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/solr-instance-017/./collection1/data/index.20180409033240691/_0.si
 -> /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core
/test/J1/temp/solr.handler.TestReplicationHandler_9FAEE8E64FDC4AB6-001/solr-instance-017/./collection1/data/index.20180409033240475/_0.si
   [junit4]   2>at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
   [junit4]   2>at 
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
   [junit4]   2>at 
sun.nio.fs.UnixFileSystemProvider.createLink(UnixFileSystemProvider.java:476)
   [junit4]   2>at java.nio.file.Files.createLink(Files.java:1086)
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.downloadIndexFiles(IndexFetcher.java:1046)
   [junit4]   2>at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:592)
   [junit4]   2>... 4 more
[...]
   [junit4]   2> 786815 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[9FAEE8E64FDC4AB6]) [ 
   ] o.a.s.h.TestReplicationHandler Waiting for 162 docs
   [junit4]   2> 786915 INFO  (qtp18488161-9808) [x:collection1] 
o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
params={q=*:*=id+desc=javabin=2} hits=107 status=0 QTime=0
   [junit4]   2> 786915 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[9FAEE8E64FDC4AB6]) [ 
   ] o.a.s.h.TestReplicationHandler Waited for 3ms and found 107 docs
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestReplicationHandler -Dtests.method=doTestStressReplication 
-Dtests.seed=9FAEE8E64FDC4AB6 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=et-EE -Dtests.timezone=Africa/Tripoli -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 31.0s J1 | TestReplicationHandler.doTestStressReplication 
<<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<162> but 
was:<107>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([9FAEE8E64FDC4AB6:4405E8204AF42305]:0)
   [junit4]>at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:904)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}

> Differential file copy for IndexFetcher
> ---
>
> Key: SOLR-11920
> URL: https://issues.apache.org/jira/browse/SOLR-11920
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11920.patch, SOLR-11920.patch, 
> apache.Lucene.Solr.NightlyTests.master.1526.log.txt.gz
>
>
> In the case of fullCopy=true, all files are copied 

[jira] [Updated] (SOLR-11920) Differential file copy for IndexFetcher

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11920:
--
Attachment: apache.Lucene.Solr.NightlyTests.master.1526.log.txt.gz

> Differential file copy for IndexFetcher
> ---
>
> Key: SOLR-11920
> URL: https://issues.apache.org/jira/browse/SOLR-11920
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11920.patch, SOLR-11920.patch, 
> apache.Lucene.Solr.NightlyTests.master.1526.log.txt.gz
>
>
> In the case of fullCopy=true, all files are copied over from the 
> leader/master irrespective of whether or not that exact file exists with the 
> replica/slave. This is wasteful, esp. in tlog replicas or pull replicas, when 
> only a fraction of the total files are different.
> This stems from SOLR-11815.



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

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4565 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds

Error Message:
failed to create testMixedBounds_collection Live Nodes: [127.0.0.1:51065_solr, 
127.0.0.1:51066_solr] Last available state: 
DocCollection(testMixedBounds_collection//collections/testMixedBounds_collection/state.json/23)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{   
"range":"8000-",   "state":"active",   "replicas":{ 
"core_node3":{   
"core":"testMixedBounds_collection_shard1_replica_n1",   
"base_url":"http://127.0.0.1:51065/solr;,   
"node_name":"127.0.0.1:51065_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}, "core_node5":{   
"core":"testMixedBounds_collection_shard1_replica_n2",   
"base_url":"http://127.0.0.1:51066/solr;,   
"node_name":"127.0.0.1:51066_solr",   "state":"active",   
"type":"NRT"}}}, "shard2":{   "range":"0-7fff",   
"state":"inactive",   "replicas":{ "core_node7":{   
"core":"testMixedBounds_collection_shard2_replica_n4",   
"base_url":"http://127.0.0.1:51065/solr;,   
"node_name":"127.0.0.1:51065_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}, "core_node8":{   
"core":"testMixedBounds_collection_shard2_replica_n6",   
"base_url":"http://127.0.0.1:51066/solr;,   
"node_name":"127.0.0.1:51066_solr",   "state":"active",   
"type":"NRT"}},   "stateTimestamp":"1523575435946949150"}, "shard2_0":{ 
  "range":"0-3fff",   "state":"active",   "replicas":{ 
"core_node11":{   
"core":"testMixedBounds_collection_shard2_0_replica_n9",   
"base_url":"http://127.0.0.1:51065/solr;,   
"node_name":"127.0.0.1:51065_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}, "core_node13":{   
"core":"testMixedBounds_collection_shard2_0_replica0",   
"base_url":"http://127.0.0.1:51065/solr;,   
"node_name":"127.0.0.1:51065_solr",   "state":"active",   
"type":"NRT"}},   "stateTimestamp":"1523575435946985867"}, "shard2_1":{ 
  "range":"4000-7fff",   "state":"active",   "replicas":{   
  "core_node12":{   
"core":"testMixedBounds_collection_shard2_1_replica_n10",   
"base_url":"http://127.0.0.1:51065/solr;,   
"node_name":"127.0.0.1:51065_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}, "core_node14":{   
"core":"testMixedBounds_collection_shard2_1_replica0",   
"base_url":"http://127.0.0.1:51066/solr;,   
"node_name":"127.0.0.1:51066_solr",   "state":"active",   
"type":"NRT"}},   "stateTimestamp":"1523575435946969840"}},   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: failed to create testMixedBounds_collection
Live Nodes: [127.0.0.1:51065_solr, 127.0.0.1:51066_solr]
Last available state: 
DocCollection(testMixedBounds_collection//collections/testMixedBounds_collection/state.json/23)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{
"shard1":{
  "range":"8000-",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"testMixedBounds_collection_shard1_replica_n1",
  "base_url":"http://127.0.0.1:51065/solr;,
  "node_name":"127.0.0.1:51065_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"},
"core_node5":{
  "core":"testMixedBounds_collection_shard1_replica_n2",
  "base_url":"http://127.0.0.1:51066/solr;,
  "node_name":"127.0.0.1:51066_solr",
  "state":"active",
  "type":"NRT"}}},
"shard2":{
  "range":"0-7fff",
  "state":"inactive",
  "replicas":{
"core_node7":{
  "core":"testMixedBounds_collection_shard2_replica_n4",
  "base_url":"http://127.0.0.1:51065/solr;,
  "node_name":"127.0.0.1:51065_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"},
"core_node8":{
  "core":"testMixedBounds_collection_shard2_replica_n6",
  "base_url":"http://127.0.0.1:51066/solr;,
  "node_name":"127.0.0.1:51066_solr",
  "state":"active",
  "type":"NRT"}},
  "stateTimestamp":"1523575435946949150"},
"shard2_0":{
  "range":"0-3fff",
  "state":"active",
  "replicas":{
"core_node11":{
  "core":"testMixedBounds_collection_shard2_0_replica_n9",
   

[jira] [Commented] (SOLR-12219) Autoscaling trigger to forceleader

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-12219:
---

This seems dangerous. This could potentially lead to loss of data and the 
sysadmins have no clue that it fired. At least if they have to send it manually 
then they have some chance of remembering why data disappeared.

> Autoscaling trigger to forceleader
> --
>
> Key: SOLR-12219
> URL: https://issues.apache.org/jira/browse/SOLR-12219
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Priority: Major
>
> In a scenario where a shard doesn't have a leader for an extended period of 
> time, it would be nice if we can configure a trigger to fire a FORCELEADER 
> API call
>  
> FORCELEADER is the first step an ops person would fire today to come out of 
> the leaderless shard scenario and if this could be automated then it would be 
> useful for teams
>  
>  



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

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

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[Tapan Vaishnav (JIRA)]

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

Tapan Vaishnav commented on SOLR-11913:
---

[~dsmiley]
Thanks for the updated patch.
{quote}Added more Javadocs, not just to the new methods here
{quote}
Thanks for the Javadocs, I'll keep in mind about the manner from next time 
onwards.
{quote}added a convenience method: public Stream> 
stream()
{quote}
We are not using the _Override_  annotation for the stream function, so isn't 
it better to re-order it about the iterator function for better code style?

Thank you for all your feedbacks, there were really helpful. 

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

[jira] [Commented] (SOLR-11033) Move out multi language field and fieldType to a separate example

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11033:
--

How about this approach:
 * Remove the different languages them from the default configset
 * We don't add a kitchen_sink_configset 
 * When a user tries to create a collection using "./bin/solr create -c 
collection_name" provide a flag to "enable language support".  We'll use the 
SolrJ Schema API and add the necessary fieldtypes and dynamic fields 
It could even be more granular like "add all languages" or "add Japanese" if we 
want it to

> Move out multi language field and fieldType to a separate example 
> --
>
> Key: SOLR-11033
> URL: https://issues.apache.org/jira/browse/SOLR-11033
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples
>Reporter: Varun Thacker
>Priority: Major
>
> The bulk of the schema file in the default configset has fieldType and 
> dynamic field definition for  different languages.  Based on the discussion 
> on SOLR-10967 if we move it to a separate config set and keep the default 
> configset english only then the size will be dramatically reduced and make 
> the schema file much more readable.



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

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

[jira] [Created] (SOLR-12219) Autoscaling trigger to forceleader

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12219:


 Summary: Autoscaling trigger to forceleader
 Key: SOLR-12219
 URL: https://issues.apache.org/jira/browse/SOLR-12219
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: AutoScaling
Reporter: Varun Thacker


In a scenario where a shard doesn't have a leader for an extended period of 
time, it would be nice if we can configure a trigger to fire a FORCELEADER API 
call

 

FORCELEADER is the first step an ops person would fire today to come out of the 
leaderless shard scenario and if this could be automated then it would be 
useful for teams

 

 



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

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1003 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23734 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 2198 links (1753 relative) to 3011 anchors in 244 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 = 

[jira] [Assigned] (SOLR-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target

[Varun Thacker (JIRA)]

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

Varun Thacker reassigned SOLR-11724:


Assignee: Varun Thacker

> Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
> -
>
> Key: SOLR-11724
> URL: https://issues.apache.org/jira/browse/SOLR-11724
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.1
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, 
> SOLR-11724.patch, SOLR-11724.patch
>
>
> Please find the discussion on:
> http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html
> If we index significant documents in to Source, stop indexing and then start 
> CDCR; bootstrapping only copies the index to leader node of shards of the 
> collection, and followers never receive the documents / index until and 
> unless atleast one document is inserted again on source; which propels to 
> target and target collection trigger index replication to followers.
> This behavior needs to be addressed in proper manner, either at target 
> collection or while bootstrapping.



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressUpdateSameID

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:904)
at org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:1243)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:327)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressUpdateSameID(TestIndexingSequenceNumbers.java:126)
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)
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)
Caused by: java.lang.AssertionError: docValues generation is still uninitialized
at 
org.apache.lucene.index.PendingSoftDeletes.onDocValuesUpdate(PendingSoftDeletes.java:123)
at 
org.apache.lucene.index.ReadersAndUpdates.handleNumericDVUpdates(ReadersAndUpdates.java:347)
at 
org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:652)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.release(IndexWriter.java:619)
at 

[jira] [Issue Comment Deleted] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12150:

Comment: was deleted

(was: Thanks Varun for polishing.)

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12150.patch, SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Resolved] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-12150.
--
   Resolution: Fixed
 Assignee: Varun Thacker
Fix Version/s: master (8.0)
   7.4

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12150.patch, SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Commented] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12150:
--

Thanks Steve and Amrit!

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12150.patch, SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Commented] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12150:
--

Added CHANGES entry and also made a slight modification where the source will 
always have the new document as we are calling a commit. So we don't need the 
additional null check 
{code:java}
assertEquals("cluster 2 wrong doc", "ABC", 
response.getResults().get(0).get(atomicFieldName));{code}

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12150.patch, SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Commented] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12150:


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

SOLR-12150: Fix a test bug in CdcrBidirectionalTest.testBiDir

(cherry picked from commit 2a2a0b6)


> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12150.patch, SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Commented] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12150:


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

SOLR-12150: Fix a test bug in CdcrBidirectionalTest.testBiDir


> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12150.patch, SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 544 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/544/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC

17 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([5ABC9E116202247A:905DCA18013B180]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:401)
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.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 

[jira] [Updated] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12150:
-
Attachment: SOLR-12150.patch

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12150.patch, SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Created] (SOLR-12218) solr.cmd will skip part of help text due to missing special character quote

[Alexandre Rafalovitch (JIRA)]

Alexandre Rafalovitch created SOLR-12218:


 Summary: solr.cmd will skip part of help text due to missing 
special character quote
 Key: SOLR-12218
 URL: https://issues.apache.org/jira/browse/SOLR-12218
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Affects Versions: 7.1
 Environment: Windows
Reporter: Alexandre Rafalovitch
Assignee: Alexandre Rafalovitch


SOLR-11084 introduced some help text that was not properly escaped in Windows 
batch file (solr.cmd), cause an - easy to miss - error message and truncated 
help information for the _bin\solr start -help_ command (anything after -t 
option).

The fix is to either quote the whole line (done in other part of the file) or 
quote the specific (less than and more than) characters, which for the echo 
command is done with the ^ character, just as it is used a couple of lines 
lower in the same file.



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

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

[jira] [Commented] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-12150:
-

Thanks Varun for polishing.

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Commented] (SOLR-12006) Add back '*_t' dynamic field for single valued text fields

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12006:
--

Thanks Alexandre ,

I marked the issue as resolved.

> Add back '*_t' dynamic field for single valued text fields
> --
>
> Key: SOLR-12006
> URL: https://issues.apache.org/jira/browse/SOLR-12006
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-12006.patch, SOLR-12006.patch, SOLR-12006.patch
>
>
> Solr used to have a '_t' dynamic field which was single valued and a "_txt" 
> field for multi-valued text 
>  
> Solr 4.x : 
> [https://github.com/apache/lucene-solr/blob/branch_4x/solr/example/example-schemaless/solr/collection1/conf/schema.xml#L129]
>  
>  
> Somewhere in Solr 5.x both became the same definition . 
> [https://github.com/apache/lucene-solr/blob/branch_5_4/solr/server/solr/configsets/data_driven_schema_configs/conf/managed-schema#L138]
>  
> In master now there is no "_t" dynamic field anymore. 
>  
> We have a single-valued dynamic field and multi-valued dynamic field for 
> ints, longs, boolean, float, date , string . We should provide the same 
> option for a text field



--
This message was sent by Atlassian 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-12006) Add back '*_t' dynamic field for single valued text fields

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-12006.
--
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.3

> Add back '*_t' dynamic field for single valued text fields
> --
>
> Key: SOLR-12006
> URL: https://issues.apache.org/jira/browse/SOLR-12006
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-12006.patch, SOLR-12006.patch, SOLR-12006.patch
>
>
> Solr used to have a '_t' dynamic field which was single valued and a "_txt" 
> field for multi-valued text 
>  
> Solr 4.x : 
> [https://github.com/apache/lucene-solr/blob/branch_4x/solr/example/example-schemaless/solr/collection1/conf/schema.xml#L129]
>  
>  
> Somewhere in Solr 5.x both became the same definition . 
> [https://github.com/apache/lucene-solr/blob/branch_5_4/solr/server/solr/configsets/data_driven_schema_configs/conf/managed-schema#L138]
>  
> In master now there is no "_t" dynamic field anymore. 
>  
> We have a single-valued dynamic field and multi-valued dynamic field for 
> ints, longs, boolean, float, date , string . We should provide the same 
> option for a text field



--
This message was sent by Atlassian 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-12181) Add trigger based on document count

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-12181:
---

Reopening because {{IndexSizeTriggerTest}} is failing pretty regularly on 
Jenkins, e.g. from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7267/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=IndexSizeTriggerTest -Dtests.method=testMergeIntegration 
-Dtests.seed=FE63E1B6D4971EC0 -Dtests.slow=true -Dtests.locale=smn 
-Dtests.timezone=Antarctica/Mawson -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.19s J0 | IndexSizeTriggerTest.testMergeIntegration <<<
   [junit4]> Throwable #1: java.io.IOException: 
java.util.concurrent.ExecutionException: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([FE63E1B6D4971EC0:ADDAA30636868B3A]:0)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.sim.SimCloudManager.request(SimCloudManager.java:540)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.sim.SimCloudManager$1.request(SimCloudManager.java:414)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.deleteById(SolrClient.java:753)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.deleteById(SolrClient.java:716)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:394)
   [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]> Caused by: java.util.concurrent.ExecutionException: 
java.lang.NullPointerException
   [junit4]>at 
java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
   [junit4]>at 
java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.sim.SimCloudManager.request(SimCloudManager.java:538)
   [junit4]>... 43 more
   [junit4]> Caused by: java.lang.NullPointerException
   [junit4]>at 
org.apache.solr.cloud.autoscaling.sim.SimClusterStateProvider.simUpdate(SimClusterStateProvider.java:1052)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.sim.SimCloudManager.simHandleSolrRequest(SimCloudManager.java:592)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.sim.SimCloudManager.lambda$request$12(SimCloudManager.java:537)
   [junit4]>at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
   [junit4]>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
   [junit4]>at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
   [junit4]>at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
   [junit4]>... 1 more
{noformat}

and from 
[http://jenkins.sarowe.net/job/Lucene-Solr-reproduce-failed-tests/2192/]:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=IndexSizeTriggerTest -Dtests.method=testTrigger 
-Dtests.seed=3C32A492BBE03B99 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=sv-SE -Dtests.timezone=Pacific/Chatham -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.41s J10 | IndexSizeTriggerTest.testTrigger <<<
   [junit4]> Throwable #1: java.lang.AssertionError: waitFor not elapsed 
but produced an event
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([3C32A492BBE03B99:5FF99210222F48B4]:0)
   [junit4]>at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger(IndexSizeTriggerTest.java:177)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}

and 

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=IndexSizeTriggerTest -Dtests.method=testSplitIntegration 
-Dtests.seed=3C32A492BBE03B99 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=sv-SE -Dtests.timezone=Pacific/Chatham -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.82s J12 | IndexSizeTriggerTest.testSplitIntegration <<<
   [junit4]> Throwable #1: java.util.concurrent.TimeoutException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([3C32A492BBE03B99:5BC1DD2941FF267]:0)
   [junit4]>at 

[jira] [Commented] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8248:
--

OK, I restored {{TestNoMergePolicy.testMethodsOverriden}} and the overridden 
methods in {{NoMergePolicy}}

> Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
> --
>
> Key: LUCENE-8248
> URL: https://issues.apache.org/jira/browse/LUCENE-8248
> Project: Lucene - Core
>  Issue Type: Wish
>  Components: core/index
>Reporter: Mike Sokolov
>Priority: Minor
> Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, 
> LUCENE-8248.patch, MergePolicy.patch
>
>
> MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is 
> not, which means that overriding it with anything other than a trivial 
> delegation can only lead to confusion.
> The patch makes the method final and removes the trivial implementations from 
> MergePolicyWrapper and NoMergePolicy.
> [~mikemccand] also pointed out that the class name is nonstandard for similar 
> adapter classes in Lucene, which are usually Filter*.java. Personally I was 
> looking for MergePolicyAdapter, but if there is a prevailing convention here 
> around Filter, does it make sense to change this class's name to 
> FilterMergePolicy?



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

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

[jira] [Updated] (LUCENE-8248) Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy

[Mike Sokolov (JIRA)]

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

Mike Sokolov updated LUCENE-8248:
-
Attachment: LUCENE-8248.2.patch

> Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy
> --
>
> Key: LUCENE-8248
> URL: https://issues.apache.org/jira/browse/LUCENE-8248
> Project: Lucene - Core
>  Issue Type: Wish
>  Components: core/index
>Reporter: Mike Sokolov
>Priority: Minor
> Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, 
> LUCENE-8248.patch, MergePolicy.patch
>
>
> MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is 
> not, which means that overriding it with anything other than a trivial 
> delegation can only lead to confusion.
> The patch makes the method final and removes the trivial implementations from 
> MergePolicyWrapper and NoMergePolicy.
> [~mikemccand] also pointed out that the class name is nonstandard for similar 
> adapter classes in Lucene, which are usually Filter*.java. Personally I was 
> looking for MergePolicyAdapter, but if there is a prevailing convention here 
> around Filter, does it make sense to change this class's name to 
> FilterMergePolicy?



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

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

Re: Review Request 66587: SOLR-11277: Add auto hard commit setting based on tlog size

[Tomás Fernández Löbbe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66587/#review201040
---



LGTM. Left some minor comments/questions


solr/core/src/java/org/apache/solr/core/SolrConfig.java
Lines 682 (patched)


I'm guessing this is also -1



solr/core/src/java/org/apache/solr/update/CommitTracker.java
Lines 175-181 (patched)


With some bad luck we could be scheduling two commits here, rigt?



solr/core/src/test/org/apache/solr/update/MaxSizeAutoCommitTest.java
Lines 116 (patched)


Is there a way to avoid this sleep? maybe wait until there are 2 tlogs 
(with a timeout), or maybe use some internal IW method like 
`hasUncommittedChanges()`?



solr/core/src/test/org/apache/solr/update/MaxSizeAutoCommitTest.java
Lines 157 (patched)


Same as above



solr/core/src/test/org/apache/solr/update/MaxSizeAutoCommitTest.java
Lines 203 (patched)


Is this @Repeat intended to stay?


- Tomás Fernández Löbbe


On April 12, 2018, 2:57 p.m., Anshum Gupta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66587/
> ---
> 
> (Updated April 12, 2018, 2:57 p.m.)
> 
> 
> Review request for lucene.
> 
> 
> Bugs: SOLR-11277
> https://issue.apache.org/jira/browse/SOLR-11277
> 
> 
> Repository: lucene-solr
> 
> 
> Description
> ---
> 
> Posting on behalf of Rupa Shanker, who contributed this patch.
> 
> 
> Diffs
> -
> 
>   solr/core/src/java/org/apache/solr/core/SolrConfig.java 6c67645 
>   solr/core/src/java/org/apache/solr/update/CommitTracker.java 6cf7504 
>   solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java 922419c 
>   solr/core/src/java/org/apache/solr/update/TransactionLog.java 35d722b 
>   solr/core/src/java/org/apache/solr/update/UpdateLog.java fbdf616 
>   
> solr/core/src/test-files/solr/collection1/conf/bad-solrconfig-no-autocommit-tag.xml
>  PRE-CREATION 
>   solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml c8884c6 
>   solr/core/src/test/org/apache/solr/core/TestConfig.java 5a7b706 
>   solr/core/src/test/org/apache/solr/update/MaxSizeAutoCommitTest.java 
> PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/66587/diff/1/
> 
> 
> Testing
> ---
> 
> Unit tests and benchmarking results on the JIRA.
> 
> 
> Thanks,
> 
> Anshum Gupta
> 
>

[jira] [Commented] (LUCENE-8250) Should FilteringTokenFilter handle positionLength

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8250:
-

can we make a simple test case for the issue? It would help me understand it 
better. The last example we looked at, we tentatively decided that stopfilter 
was doing the right thing, so maybe we need another one.

> Should FilteringTokenFilter handle positionLength
> -
>
> Key: LUCENE-8250
> URL: https://issues.apache.org/jira/browse/LUCENE-8250
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Major
>
> FilteringTokenFilter does not handle the position length graph attribute when 
> removing a token from the stream. This doesn't work well with graph token 
> stream that sets position length since removing a token from the stream can 
> invalidate the position length set on the previous tokens. 
> This issue was first discussed in 
> https://issues.apache.org/jira/browse/LUCENE-4065 but it has a different 
> purpose which is why I am opening a new issue here.



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

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

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

[Policeman Jenkins Server]

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

22 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.request.TestUnInvertedFieldException

Error Message:
ObjectTracker found 3 object(s) that were not released!!! [SolrCore, 
SolrIndexSearcher, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1040)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:864)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1051)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:647)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.search.SolrIndexSearcher  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.search.SolrIndexSearcher.(SolrIndexSearcher.java:325)  at 
org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2047)  at 
org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2220)  at 
org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1957)  at 
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:719)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:93)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:68)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1924)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1900)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:160)
  at org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:281) 
 at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:188)  at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2508)  at 
org.apache.solr.servlet.DirectSolrConnection.request(DirectSolrConnection.java:125)
  at org.apache.solr.util.TestHarness.update(TestHarness.java:284)  at 
org.apache.solr.util.BaseTestHarness.checkUpdateStatus(BaseTestHarness.java:281)
  at 
org.apache.solr.util.BaseTestHarness.validateUpdate(BaseTestHarness.java:251)  
at org.apache.solr.SolrTestCaseJ4.checkUpdateU(SolrTestCaseJ4.java:863)  at 
org.apache.solr.SolrTestCaseJ4.assertU(SolrTestCaseJ4.java:842)  at 
org.apache.solr.SolrTestCaseJ4.assertU(SolrTestCaseJ4.java:836)  at 
org.apache.solr.request.TestUnInvertedFieldException.createIndex(TestUnInvertedFieldException.java:73)
  at 
org.apache.solr.request.TestUnInvertedFieldException.setUp(TestUnInvertedFieldException.java:55)
  at jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)  at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:564)  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:968)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
  at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
  at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
  at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
  at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
  at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
  at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
  at 

Re: When did we stop shipping changes.html?

[Cassandra Targett]

I won’t speak for Jan and Uwe who worked on the patches there, but my feeling 
is that it was specifically intended - the CHANGES entry for SOLR-9450 says as 
much. 

Changes.html & associated files are built with the same ant target 
(“documentation”) that builds javadocs. I think it was assumed that everyone 
knew that (or would investigate if they had an interest), and would understand 
that removing javadocs and replacing it with a single file would also remove 
Changes.html from the /docs directory in the package.

On Apr 12, 2018, at 3:15 PM, Alexandre Rafalovitch  wrote:
> 
> The scope of that JIRA was Javadocs specifically.
> 
> Wouldn't loosing other files, such as changes.html be an unintended
> consequences then?
> 
> Regards,
>   Alex.
> 
> On 12 April 2018 at 16:07, Cassandra Targett  wrote:
>> I believe it was in 6.5, with
>> https://issues.apache.org/jira/browse/SOLR-9450.
>> 
>> On Apr 12, 2018, at 2:45 PM, Alexandre Rafalovitch 
>> wrote:
>> 
>> The Solr's doc folder is suddenly looking scarily empty.
>> 
>> Specifically, the changes.html now seems to be only online. That quite
>> surprised me. Not that I am in love with the current changes.txt or
>> changes.html for my usual use case (finding when something became
>> available), but still.
>> 
>> Worse, I could not figure out when that changes.html file stopped
>> being shipped by trying to read or grep through changes.txt (catch-22)
>> or Jiras.
>> 
>> Could somebody please point me to the relevant issue where that was
>> discussed and executed for more context.
>> 
>> Regards,
>>  Alex.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11913:
-

Here's an updated patch. I think it's ready.
 * added a convenience method: {{public Stream> 
stream()}}
 * Added more javadocs, not just to the new methods here
 * Re-ordered what you added and the existing writeMap to fit better with the 
loose organization of existing methods
 * MultiMapSolrParams now overrides iterator().
 * changed assertEquals to assertArrayEquals where applicable in the test

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

[jira] [Updated] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11913:

Attachment: SOLR-11913.patch

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

[jira] [Commented] (SOLR-10169) PeerSync will hit an NPE on no response errors when looking for fingerprint.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10169:
---

PeerSync.alreadyInSync() eventually calls HttpShardHandler.take(), which has 
this line:

if (bailOnError && rsp.getException() != null) return rsp;

Then takes the response and throws an NPE on line 391:
  Object replicaFingerprint = 
srsp.getSolrResponse().getResponse().get("fingerprint");


It's not clear to me whether it's the getSolrResponse() or 
getSolrResponse().getResponse() that throws the error.

 The problem here is that the exception bypasses the rest of the peer sync 
logic and goes into full sync.

I'll attach a patch shortly that tests both for null. I Haven't done anything 
except compile it yet. It may still go into full sync, but at least there'll be 
a chance to recover.

I'll commit this over the weekend unless there are objections.

The line numbers match up reasonably between the various versions of that file 
for the dates of the JIRAs.


> PeerSync will hit an NPE on no response errors when looking for fingerprint.
> 
>
> Key: SOLR-10169
> URL: https://issues.apache.org/jira/browse/SOLR-10169
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 7.0
>Reporter: Mark Miller
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-10169.patch
>
>




--
This message was sent by Atlassian 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-10169) PeerSync will hit an NPE on no response errors when looking for fingerprint.

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-10169:
--
Attachment: SOLR-10169.patch

> PeerSync will hit an NPE on no response errors when looking for fingerprint.
> 
>
> Key: SOLR-10169
> URL: https://issues.apache.org/jira/browse/SOLR-10169
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-10169.patch
>
>




--
This message was sent by Atlassian 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-12006) Add back '*_t' dynamic field for single valued text fields

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-12006:
--

Has this issue been resolved? Because it is in the release notes for 7.3.0.

> Add back '*_t' dynamic field for single valued text fields
> --
>
> Key: SOLR-12006
> URL: https://issues.apache.org/jira/browse/SOLR-12006
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12006.patch, SOLR-12006.patch, SOLR-12006.patch
>
>
> Solr used to have a '_t' dynamic field which was single valued and a "_txt" 
> field for multi-valued text 
>  
> Solr 4.x : 
> [https://github.com/apache/lucene-solr/blob/branch_4x/solr/example/example-schemaless/solr/collection1/conf/schema.xml#L129]
>  
>  
> Somewhere in Solr 5.x both became the same definition . 
> [https://github.com/apache/lucene-solr/blob/branch_5_4/solr/server/solr/configsets/data_driven_schema_configs/conf/managed-schema#L138]
>  
> In master now there is no "_t" dynamic field anymore. 
>  
> We have a single-valued dynamic field and multi-valued dynamic field for 
> ints, longs, boolean, float, date , string . We should provide the same 
> option for a text field



--
This message was sent by Atlassian 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-10169) PeerSync will hit an NPE on no response errors when looking for fingerprint.

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-10169:
-

Assignee: Erick Erickson

> PeerSync will hit an NPE on no response errors when looking for fingerprint.
> 
>
> Key: SOLR-10169
> URL: https://issues.apache.org/jira/browse/SOLR-10169
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Erick Erickson
>Priority: Major
>




--
This message was sent by Atlassian 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-10169) PeerSync will hit an NPE on no response errors when looking for fingerprint.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10169:
---

Pretty certain these are the same thing. Fix coming

> PeerSync will hit an NPE on no response errors when looking for fingerprint.
> 
>
> Key: SOLR-10169
> URL: https://issues.apache.org/jira/browse/SOLR-10169
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Major
>




--
This message was sent by Atlassian 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: When did we stop shipping changes.html?

[Alexandre Rafalovitch]

The scope of that JIRA was Javadocs specifically.

Wouldn't loosing other files, such as changes.html be an unintended
consequences then?

Regards,
   Alex.

On 12 April 2018 at 16:07, Cassandra Targett  wrote:
> I believe it was in 6.5, with
> https://issues.apache.org/jira/browse/SOLR-9450.
>
> On Apr 12, 2018, at 2:45 PM, Alexandre Rafalovitch 
> wrote:
>
> The Solr's doc folder is suddenly looking scarily empty.
>
> Specifically, the changes.html now seems to be only online. That quite
> surprised me. Not that I am in love with the current changes.txt or
> changes.html for my usual use case (finding when something became
> available), but still.
>
> Worse, I could not figure out when that changes.html file stopped
> being shipped by trying to read or grep through changes.txt (catch-22)
> or Jiras.
>
> Could somebody please point me to the relevant issue where that was
> discussed and executed for more context.
>
> Regards,
>   Alex.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

Re: When did we stop shipping changes.html?

[Cassandra Targett]

I believe it was in 6.5, with https://issues.apache.org/jira/browse/SOLR-9450 
.

> On Apr 12, 2018, at 2:45 PM, Alexandre Rafalovitch  wrote:
> 
> The Solr's doc folder is suddenly looking scarily empty.
> 
> Specifically, the changes.html now seems to be only online. That quite
> surprised me. Not that I am in love with the current changes.txt or
> changes.html for my usual use case (finding when something became
> available), but still.
> 
> Worse, I could not figure out when that changes.html file stopped
> being shipped by trying to read or grep through changes.txt (catch-22)
> or Jiras.
> 
> Could somebody please point me to the relevant issue where that was
> discussed and executed for more context.
> 
> Regards,
>   Alex.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

When did we stop shipping changes.html?

[Alexandre Rafalovitch]

The Solr's doc folder is suddenly looking scarily empty.

Specifically, the changes.html now seems to be only online. That quite
surprised me. Not that I am in love with the current changes.txt or
changes.html for my usual use case (finding when something became
available), but still.

Worse, I could not figure out when that changes.html file stopped
being shipped by trying to read or grep through changes.txt (catch-22)
or Jiras.

Could somebody please point me to the relevant issue where that was
discussed and executed for more context.

Regards,
   Alex.

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 560 - Still Failing

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [Overseer] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.cloud.Overseer  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.cloud.Overseer.start(Overseer.java:545)  at 
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:851)
  at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170) 
 at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)  
at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)  at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)  at 
org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:2069)
  at 
org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:331)
  at java.lang.Thread.run(Thread.java:748)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [Overseer]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.cloud.Overseer
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at org.apache.solr.cloud.Overseer.start(Overseer.java:545)
at 
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:851)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)
at 
org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:2069)
at 
org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:331)
at java.lang.Thread.run(Thread.java:748)


at __randomizedtesting.SeedInfo.seed([866C23E2775A7BA0]: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.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:303)
at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
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$7.evaluate(RandomizedRunner.java:897)
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:  junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.cloud.ZkControllerTest: 
1) 

[jira] [Reopened] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

[David Smiley (JIRA)]

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

David Smiley reopened SOLR-11913:
-

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch, 
> SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



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

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

[jira] [Commented] (SOLR-12216) Add support for cross-cloud join

[Horatiu Lazu (JIRA)]

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

Horatiu Lazu commented on SOLR-12216:
-

I'm still doing some finishing touches, hoping to get it out soon, but would 
like some feedback at this point on the idea itself. 

> Add support for cross-cloud join 
> -
>
> Key: SOLR-12216
> URL: https://issues.apache.org/jira/browse/SOLR-12216
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Horatiu Lazu
>Priority: Major
>
> This patch is to propose the idea of extending the capabilities of the 
> built-in join to allow joining across SolrClouds. Similar to streaming's 
> search function, the user can directly specify the zkHost of the other 
> SolrCloud and the rest of the syntax (from, to, fromIndex) can remain the 
> same. This join would be triggered when the zkHost parameter is specified, 
> containing the address of the other SolrCluster. It could also be packaged as 
> a separate plugin.
>  
> In my testing, my current implementation is on average 4.5x faster than an 
> equivalent streaming expression intersecting from two search queries, one of 
> which streams from another collection on another SolrCloud. 
> h5. How it works
> Similar to the existing join, I created a QParser, but this join works as a 
> post-filter. The join first populates a hash set containing fields from the 
> “from” index (i.e, the index that’s not the one we’re running the query 
> from). To obtain the fields, it establishes a connection with the other 
> SolrCloud using SolrJ through the ZooKeeper address specified, and then uses 
> a custom request handler that performs the query on the “from” index and 
> return back an array of strings containing a list of fields. Then, on the 
> “to” index, it iterates through the array sent as JavaBin and adds it to the 
> hash set. After that, we iterate through the NumericDocList for the “to” 
> core’s join field, and if there’s a value within the NumericDocList that’s 
> found within our hash set, we collect it inside the DelegatingCollector.
> This allows for joining across sharded collections as well. 
> h5. How I benchmarked
> I created web-app that first reloads the collections, then sends 25 AJAX 
> requests at once to the Solr endpoint of varying query sizes (between 127 
> search results and 690,000), and then recorded the results. After all 
> responses are returned, the collection is reloaded, and the equivalent 
> streaming expressions are tested. This process is repeated 15 times, and the 
> average of the results is taken. 
> Note: The first two requests are not counted in the statistics, because it 
> “warms up” the collection. For reference, after bouncing Solr and at least 
> one query is executed, it takes on average ~890ms for joining on two 
> collections with about 690,000 results, while it takes ~4.5 seconds using 
> streaming expressions).
>  
> I have written unit tests written as well. I would appreciate some comments 
> on this. Thank you.



--
This message was sent by Atlassian 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-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12150:
--

Thanks Amrit! 

Uploaded a slightly modified patch. Running tests and will commit it shortly.

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Updated] (SOLR-12150) CdcrBidirectionalTest.testBiDir() reproducing failure

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12150:
-
Attachment: SOLR-12150.patch

> CdcrBidirectionalTest.testBiDir() reproducing failure
> -
>
> Key: SOLR-12150
> URL: https://issues.apache.org/jira/browse/SOLR-12150
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, Tests
>Reporter: Steve Rowe
>Priority: Major
> Attachments: SOLR-12150.patch, SOLR-12150.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/] (also 
> reproduces for me on Linux):
> {noformat}
> Checking out Revision e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=CdcrBidirectionalTest -Dtests.method=testBiDir 
> -Dtests.seed=38DB802FA0173E8D -Dtests.slow=true -Dtests.locale=ro-RO 
> -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   23.3s J0 | CdcrBidirectionalTest.testBiDir <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 0, 
> Size: 0
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
>[junit4]>  at java.util.ArrayList.rangeCheck(ArrayList.java:653)
>[junit4]>  at java.util.ArrayList.get(ArrayList.java:429)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
>[junit4]>  at 
> org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ro-RO, timezone=Etc/GMT-8
>[junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 1.8.0_144 
> (64-bit)/cpus=3,threads=1,free=160960440,total=347418624
> {noformat}



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

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

[jira] [Updated] (SOLR-12216) Add support for cross-cloud join

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-12216:

Priority: Major  (was: Trivial)

> Add support for cross-cloud join 
> -
>
> Key: SOLR-12216
> URL: https://issues.apache.org/jira/browse/SOLR-12216
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Horatiu Lazu
>Priority: Major
>
> This patch is to propose the idea of extending the capabilities of the 
> built-in join to allow joining across SolrClouds. Similar to streaming's 
> search function, the user can directly specify the zkHost of the other 
> SolrCloud and the rest of the syntax (from, to, fromIndex) can remain the 
> same. This join would be triggered when the zkHost parameter is specified, 
> containing the address of the other SolrCluster. It could also be packaged as 
> a separate plugin.
>  
> In my testing, my current implementation is on average 4.5x faster than an 
> equivalent streaming expression intersecting from two search queries, one of 
> which streams from another collection on another SolrCloud. 
> h5. How it works
> Similar to the existing join, I created a QParser, but this join works as a 
> post-filter. The join first populates a hash set containing fields from the 
> “from” index (i.e, the index that’s not the one we’re running the query 
> from). To obtain the fields, it establishes a connection with the other 
> SolrCloud using SolrJ through the ZooKeeper address specified, and then uses 
> a custom request handler that performs the query on the “from” index and 
> return back an array of strings containing a list of fields. Then, on the 
> “to” index, it iterates through the array sent as JavaBin and adds it to the 
> hash set. After that, we iterate through the NumericDocList for the “to” 
> core’s join field, and if there’s a value within the NumericDocList that’s 
> found within our hash set, we collect it inside the DelegatingCollector.
> This allows for joining across sharded collections as well. 
> h5. How I benchmarked
> I created web-app that first reloads the collections, then sends 25 AJAX 
> requests at once to the Solr endpoint of varying query sizes (between 127 
> search results and 690,000), and then recorded the results. After all 
> responses are returned, the collection is reloaded, and the equivalent 
> streaming expressions are tested. This process is repeated 15 times, and the 
> average of the results is taken. 
> Note: The first two requests are not counted in the statistics, because it 
> “warms up” the collection. For reference, after bouncing Solr and at least 
> one query is executed, it takes on average ~890ms for joining on two 
> collections with about 690,000 results, while it takes ~4.5 seconds using 
> streaming expressions).
>  
> I have written unit tests written as well. I would appreciate some comments 
> on this. Thank you.



--
This message was sent by Atlassian 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-12216) Add support for cross-cloud join

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-12216:
-

Where is the patch that you've referred to in the description?

> Add support for cross-cloud join 
> -
>
> Key: SOLR-12216
> URL: https://issues.apache.org/jira/browse/SOLR-12216
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Horatiu Lazu
>Priority: Trivial
>
> This patch is to propose the idea of extending the capabilities of the 
> built-in join to allow joining across SolrClouds. Similar to streaming's 
> search function, the user can directly specify the zkHost of the other 
> SolrCloud and the rest of the syntax (from, to, fromIndex) can remain the 
> same. This join would be triggered when the zkHost parameter is specified, 
> containing the address of the other SolrCluster. It could also be packaged as 
> a separate plugin.
>  
> In my testing, my current implementation is on average 4.5x faster than an 
> equivalent streaming expression intersecting from two search queries, one of 
> which streams from another collection on another SolrCloud. 
> h5. How it works
> Similar to the existing join, I created a QParser, but this join works as a 
> post-filter. The join first populates a hash set containing fields from the 
> “from” index (i.e, the index that’s not the one we’re running the query 
> from). To obtain the fields, it establishes a connection with the other 
> SolrCloud using SolrJ through the ZooKeeper address specified, and then uses 
> a custom request handler that performs the query on the “from” index and 
> return back an array of strings containing a list of fields. Then, on the 
> “to” index, it iterates through the array sent as JavaBin and adds it to the 
> hash set. After that, we iterate through the NumericDocList for the “to” 
> core’s join field, and if there’s a value within the NumericDocList that’s 
> found within our hash set, we collect it inside the DelegatingCollector.
> This allows for joining across sharded collections as well. 
> h5. How I benchmarked
> I created web-app that first reloads the collections, then sends 25 AJAX 
> requests at once to the Solr endpoint of varying query sizes (between 127 
> search results and 690,000), and then recorded the results. After all 
> responses are returned, the collection is reloaded, and the equivalent 
> streaming expressions are tested. This process is repeated 15 times, and the 
> average of the results is taken. 
> Note: The first two requests are not counted in the statistics, because it 
> “warms up” the collection. For reference, after bouncing Solr and at least 
> one query is executed, it takes on average ~890ms for joining on two 
> collections with about 690,000 results, while it takes ~4.5 seconds using 
> streaming expressions).
>  
> I have written unit tests written as well. I would appreciate some comments 
> on this. Thank you.



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

Karl Wright commented on LUCENE-8245:
-

[~dsmiley] I ran it.  Took 25 minutes.
Don't understand why it didn't detect this.


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

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

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

LUCENE-8245: fix unused import


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