[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+120) - Build # 815 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/815/
Java: 64bit/jdk-9-ea+120 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:34685/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:34685/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([DB92D350573236C9:53C6EC8AF9CE5B31]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7312:
-

Hmm, looking at what I did for Geo3DDocValuesField, and trying to see whether 
it would suffer from the same issue, it looks like I did something somewhat 
different:

{code}
  private static int encodeX(final double x) {
if (x > PlanetModel.WGS84.getMaximumXValue()) {
  throw new IllegalArgumentException("x value exceeds WGS84 maximum");
} else if (x < PlanetModel.WGS84.getMinimumXValue()) {
  throw new IllegalArgumentException("x value less than WGS84 minimum");
}
return (int)Math.floor((x - PlanetModel.WGS84.getMinimumXValue()) * xFactor 
+ 0.5);
  }
  
  private static double decodeX(final int x) {
return x * inverseXFactor + PlanetModel.WGS84.getMinimumXValue();
  }
{code}

... where xFactor and inverseXFactor are related such that inverseXFactor = 
1.0/xFactor.  Basically, by adding the 0.5 right before floor time I made sure 
no such effects could happen?  I think??  This stuff makes my head hurt...


> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7312.patch
>
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-7312) Geo3dPoint test failure

[Karl Wright (JIRA)]

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

Karl Wright edited comment on LUCENE-7312 at 6/3/16 4:31 AM:
-

Ok, NVM, in the context of your comment above I see what it's trying to do, and 
it looks like it does that.  So I think this solution is fine.



was (Author: kwri...@metacarta.com):
Ok, NVM, in the context of your comment above I see what it's trying to do, and 
it looks like it does that.  I still can't wrap my head around the "why" 
though.  I'm missing some history...


> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7312.patch
>
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7312:
-

Ok, NVM, in the context of your comment above I see what it's trying to do, and 
it looks like it does that.  I still can't wrap my head around the "why" 
though.  I'm missing some history...


> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7312.patch
>
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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 # 624 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/624/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestDownShardTolerantSearch.searchingShouldFailWithoutTolerantSearchSetToTrue

Error Message:
Error message from server should have the name of the down shard

Stack Trace:
java.lang.AssertionError: Error message from server should have the name of the 
down shard
at 
__randomizedtesting.SeedInfo.seed([CFC46D10AFC7D504:FD14CC1BAA65B465]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestDownShardTolerantSearch.searchingShouldFailWithoutTolerantSearchSetToTrue(TestDownShardTolerantSearch.java:68)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 183 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/183/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica2","base_url":"http://127.0.0.1:62249","node_name":"127.0.0.1:62249_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:62217;,   
"core":"c8n_1x3_lf_shard1_replica1",   "node_name":"127.0.0.1:62217_"}, 
"core_node2":{   "core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:62225;,   "node_name":"127.0.0.1:62225_",  
 "state":"down"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica2",   
"base_url":"http://127.0.0.1:62249;,   "node_name":"127.0.0.1:62249_",  
 "state":"active",   "leader":"true",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica2","base_url":"http://127.0.0.1:62249","node_name":"127.0.0.1:62249_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:62217;,
  "core":"c8n_1x3_lf_shard1_replica1",
  "node_name":"127.0.0.1:62217_"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:62225;,
  "node_name":"127.0.0.1:62225_",
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:62249;,
  "node_name":"127.0.0.1:62249_",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([24D191C19021B1EE:AC85AE1B3EDDDC16]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:168)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWatchesWorkForStateFormat1

Error Message:
CollectionStateWatcher not notified of stateformat=1 collection creation

Stack Trace:
java.lang.AssertionError: CollectionStateWatcher not notified of stateformat=1 
collection creation
at 
__randomizedtesting.SeedInfo.seed([3011B606D36DAB04:57D6AAE827D58FA5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWatchesWorkForStateFormat1(TestCollectionStateWatchers.java:267)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12831 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16906 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16906/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val' for path 'response/params/y/c' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":0, "params":{"x":{ "a":"A val", "b":"B 
val", "":{"v":0},  from server:  https://127.0.0.1:45204/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":0,
"params":{"x":{
"a":"A val",
"b":"B val",
"":{"v":0},  from server:  https://127.0.0.1:45204/collection1
at 
__randomizedtesting.SeedInfo.seed([353609C8A1476FA:8B075F4624E81B02]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:160)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[Hoss Man (JIRA)]

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

Hoss Man updated LUCENE-7132:
-
Attachment: LUCENE-7132.patch


I was reminded of this issue today and pinged [~mikemccand] about it on IRC.

In reviewing the issue myself, to try and describe it to him succinctly, I 
realized the key bullet points of this bug is:

* It is possible to build an index, _with *no* deleted documents_ such that a 
particular BooleanQuery returns drastically different scores for some documents 
depending on if/how the segments in the index have been merged.
* The Explanations for every document matching this BooleanQuery do *not* 
change based on if/how the segments in the index have been merged -- such that 
the Explanations can be drastically different then the scores

Couched that way, and with a request from mike to try and confirm if the bug 
was dependent on using LuceneTestCase.newIndexWriterConfig (i gather he 
suspected it might be a test only bug) I revamped the previous test class to 
attempt to more straight forwardly demonstrate the crux of the matter.

There are now two test methods: testScoresWithDefaultIWC & 
testScoresWithRandomIWC -- both delegating to the same helpe method for the 
meat of the test, just using different IndexWriterConfigs.

"checkScores" is the meat of both test methods.  It builds up an index using 
the same "RajeshData.txt" and then executes a fixed query against the index, 
recording the scores of every mathcing document.  It then does a 
{{forceMerge(1,true)}} on the IndexWriter, and re-executes the query comparing 
the scores of every matching document against the scores from the previous 
query execution.

If the tests make it this far (and they rarely do) then does the query again, 
this time checking the "Explanation" for every matching document against the 
score.



With this seed, both tests demonstrate an identical inconsistency between the 
scores of a document containing body="Microsoft Office 365" between the 
pre-merge and single-segment indexes

{noformat}
   [junit4]  says ahoj! Master seed: B6DEF72C383813DE
   [junit4] Executing 1 suite with 1 JVM.
   [junit4] 
   [junit4] Started J0 PID(29777@localhost).
   [junit4] Suite: org.apache.lucene.search.TestBooleanScoreConsistency
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestBooleanScoreConsistency -Dtests.method=testScoresWithRandomIWC 
-Dtests.seed=B6DEF72C383813DE -Dtests.slow=true -Dtests.locale=ar-IQ 
-Dtests.timezone=Asia/Jayapura -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 2.80s | TestBooleanScoreConsistency.testScoresWithRandomIWC 
<<<
   [junit4]> Throwable #1: java.lang.AssertionError: 7614: score doesn't 
match (previously returned) expected score for Microsoft Office 365 
expected:<1.2357021570205688> but was:<0.41190072894096375>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B6DEF72C383813DE:2C10E99E7CDA36F8]:0)
   [junit4]>at 
org.apache.lucene.search.TestBooleanScoreConsistency.checkScoresAgainstExpected(TestBooleanScoreConsistency.java:178)
   [junit4]>at 
org.apache.lucene.search.TestBooleanScoreConsistency.checkScores(TestBooleanScoreConsistency.java:137)
   [junit4]>at 
org.apache.lucene.search.TestBooleanScoreConsistency.testScoresWithRandomIWC(TestBooleanScoreConsistency.java:85)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestBooleanScoreConsistency -Dtests.method=testScoresWithDefaultIWC 
-Dtests.seed=B6DEF72C383813DE -Dtests.slow=true -Dtests.locale=ar-IQ 
-Dtests.timezone=Asia/Jayapura -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 1.63s | 
TestBooleanScoreConsistency.testScoresWithDefaultIWC <<<
   [junit4]> Throwable #1: java.lang.AssertionError: 7614: score doesn't 
match (previously returned) expected score for Microsoft Office 365 
expected:<1.2357021570205688> but was:<0.41190072894096375>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B6DEF72C383813DE:1CF87A1A7D4B3415]:0)
   [junit4]>at 
org.apache.lucene.search.TestBooleanScoreConsistency.checkScoresAgainstExpected(TestBooleanScoreConsistency.java:178)
   [junit4]>at 
org.apache.lucene.search.TestBooleanScoreConsistency.checkScores(TestBooleanScoreConsistency.java:137)
   [junit4]>at 
org.apache.lucene.search.TestBooleanScoreConsistency.testScoresWithDefaultIWC(TestBooleanScoreConsistency.java:79)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): 
{id=PostingsFormat(name=Direct), body=Lucene50(blocksize=128)}, docValues:{}, 
maxPointsInLeafNode=825, maxMBSortInHeap=5.5977062021908015, 
sim=RandomSimilarity(queryNorm=false,coord=crazy): {}, locale=ar-IQ, 
timezone=Asia/Jayapura
   [junit4]   2> 

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 813 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/813/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([56F2556A5267015C:20CC4A191350AC73]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326)
at 
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at 
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:384)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:327)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:377)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:443)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-Tests-master - Build # 1190 - Still Failing

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup

Error Message:
Failed to create backup

Stack Trace:
java.lang.AssertionError: Failed to create backup
at 
__randomizedtesting.SeedInfo.seed([9B3C62CAD6A632AB:DAB742AFF118C1E4]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.CheckBackupStatus.fetchStatus(CheckBackupStatus.java:50)
at 
org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup(TestReplicationHandlerBackup.java:199)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12135 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandlerBackup
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7312:
-

This looks reasonable, except for some debugging code:

{code}
@@ -1172,6 +1173,11 @@ public class TestGeo3DPoint extends LuceneTestCase {
 GeoPoint pointEnc = new 
GeoPoint(Geo3DUtil.decodeValueFloor(Geo3DUtil.encodeValue(point.x)),
  
Geo3DUtil.decodeValueFloor(Geo3DUtil.encodeValue(point.y)),
  
Geo3DUtil.decodeValueFloor(Geo3DUtil.encodeValue(point.z)));
+if (iter >= 2881) {
+  System.out.println("iter=" + iter + " i=" + i + " lat=" + lat + " 
lon=" + lon);
+  System.out.println("  point=" + point);
+  System.out.println("  pointEnc=" + pointEnc);
+}
 assertTrue(pointEnc.x <= point.x);
 assertTrue(pointEnc.y <= point.y);
 assertTrue(pointEnc.z <= point.z);
{code}

I don't actually understand what getNextSafeDouble() is intended to do, though?


> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7312.patch
>
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8676) It's not possible to use a different log4.properties file on windows

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-8676:
---
Attachment: verifying SOLR-8676.txt
SOLR-8676.patch

briefly checked in on old windows, it seems fine. see attach. Will commit 
tomorrow or so. 

> It's not possible to use a different log4.properties file on windows
> 
>
> Key: SOLR-8676
> URL: https://issues.apache.org/jira/browse/SOLR-8676
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Attachments: SOLR-8676.patch, SOLR-8676.patch, verifying SOLR-8676.txt
>
>
> It's currently not possible to change the location of the log4j.properties 
> file on windows. The value of {{LOG4J_CONFIG}} always gets replaced with the 
> default value {{server\resources\log4j.properties}}. Thus, this file inside 
> the server directory needs to be changed after every update.
> See attached patch for a fix. Unfortunately, I couldn't figure out why 
> {{LOG4J_CONFIG}} was set to empty. I tested manually that logging still works 
> when running an example so I hope that this line is really just obsolete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8522) ImplicitSnitch to support IPv4 fragment tags

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-8522:
---

I'm getting test failures due to some of the tests introduced in this ticket. I 
opened an issue at SOLR-9183

> ImplicitSnitch to support IPv4 fragment tags
> 
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8522.patch, SOLR-8522.patch, SOLR-8522.patch, 
> SOLR-8522.patch, SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> h3. IPv4 fragment tags
> Lets assume a Solr node IPv4 address is {{192.93.255.255}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{hostfrag_1 = 255}}
> - {{hostfrag_2 = 255}}
> - {{hostfrag_3 = 93}}
> - {{hostfrag_4 = 192}}
> Note that IPv6 support will be implemented by a separate ticket
> h3. Host name fragment tags
> Lets assume a Solr node host name {{serv1.dc1.country1.apache.org}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support  tags like:
> - {{hostfrag_1 = org}}
> - {{hostfrag_2 = apache}}
> - {{hostfrag_3 = country1}}
> - {{hostfrag_4 = dc1}}
> - {{hostfrag_5 = serv1}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9183) Test ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing is failing

[Keith Laban (JIRA)]

Keith Laban created SOLR-9183:
-

 Summary: Test 
ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing is 
failing
 Key: SOLR-9183
 URL: https://issues.apache.org/jira/browse/SOLR-9183
 Project: Solr
  Issue Type: Bug
Reporter: Keith Laban


This is causing tests to fail for me on 6x and master

The test introduced in SOLR-8522
{{ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing}} is 
failing for me.

{code}
java.lang.AssertionError: 
Expected: is <0>
 got: <1>

at org.junit.Assert.assertThat(Assert.java:780)
at org.junit.Assert.assertThat(Assert.java:738)
at 
org.apache.solr.cloud.rule.ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing(ImplicitSnitchTest.java:101)
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:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
{code}

I suspect that 
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/rule/ImplicitSnitch.java#L130
 should be returning null causing the failures.

I'll run the test at home to see if it has something to do with the corporate 
network I'm running on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9129) Solr Cloud hangs when creating large number of collections and node fails to recover after restart

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9129:


SolrCloud does not scale well with a very large number of collections.  See 
SOLR-7191.

> Solr Cloud hangs when creating large number of collections and node fails to 
> recover after restart
> --
>
> Key: SOLR-9129
> URL: https://issues.apache.org/jira/browse/SOLR-9129
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 6.0
> Environment: OS: GNU Linux, kernel 4.4.0-22 on x86_64 (Ubuntu Linux 
> 16.04 LTS (64-bit))
> RAM: 16 GB
> CPU: Intel Core i7-4720HQ CPU @ 2.60GHz × 8
> Java version: Oracle JDK 1.8.0_92 (x64) build 1.8.0_92-b14 Java HotSpot(TM) 
> 64-Bit Server VM (build 25.92-b14, mixed mode)
>Reporter: Peter Horvath
> Attachments: exception1.txt, exception2.txt, exception3.txt, 
> exception4.txt, solr_node_hung_after_restart.txt, 
> solr_node_hung_before_restart.txt, solr_visualvm.png, solr_visualvm2.png
>
>
> I attempted to benchmark SolrCloud to see how well it would work with some 
> sample data set of ours. 
> I wanted to create about 2500 empty collections first to see how that would 
> scale.
> Unfortunately, the test was not successful. Solr started failing after 
> creating around 2000 collections and the cluster has failed to recover after 
> a complete restart, which is quite concerning to me. 
> I based my environment on the cloud example (I use the same config set as the 
> gettingstarted example collection etc); so I have the vanilla install and 
> used the following commands to bring the nodes online:
> .../solr/6.0.0/bin/solr start -m 2g -cloud -p 8983 -s
> ".../solr/6.0.0/example/cloud/node1/solr"
> .../solr/6.0.0/bin/solr start -m 2g -cloud -p 7574 -s
> ".../solr/6.0.0/example/cloud/node2/solr" -z localhost:9983
> .../solr/6.0.0/bin/solr start -m 2g -cloud -p 8984 -s
> ".../solr/6.0.0/example/cloud/node3/solr" -z localhost:9983
> .../solr/6.0.0/bin/solr start -m 2g -cloud -p 7575 -s
> ".../solr/6.0.0/example/cloud/node4/solr" -z localhost:9983
> After about 2000 collections were created, SolR got hung; REST requests 
> started failing. I found the following entry in the logs, wihch I could 
> relate to the failed REST request. For further logs, please see the 
> attachment of this issue. 
> null:org.apache.solr.common.SolrException: Could not fully create collection: 
> FOOBAR
>   at 
> org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:266)
>   at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:197)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:658)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:441)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at 

[jira] [Updated] (LUCENE-7312) Geo3dPoint test failure

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7312:
---
Attachment: LUCENE-7312.patch

Patch, going back to "safe" doubles, and adding a better quantization test ... 
tests seem to survive some beasting.

> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7312.patch
>
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8610) DIH - Resolve variables in encryptKeyFile

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-8610:
---
Attachment: SOLR-8610.patch

> DIH - Resolve variables in encryptKeyFile
> -
>
> Key: SOLR-8610
> URL: https://issues.apache.org/jira/browse/SOLR-8610
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8610.patch, SOLR-8610.patch
>
>
> I would like to use a variable like {{$\{path.to.file\}}} for  
> {{encryptKeyFile}} in my DIH config files so that I don't have to specify the 
> concrete absolute path in all files. This is currently not possible since 
> variables are not resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8610) DIH - Resolve variables in encryptKeyFile

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-8610:
---
Attachment: (was: SOLR-8610.patch)

> DIH - Resolve variables in encryptKeyFile
> -
>
> Key: SOLR-8610
> URL: https://issues.apache.org/jira/browse/SOLR-8610
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8610.patch, SOLR-8610.patch
>
>
> I would like to use a variable like {{$\{path.to.file\}}} for  
> {{encryptKeyFile}} in my DIH config files so that I don't have to specify the 
> concrete absolute path in all files. This is currently not possible since 
> variables are not resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-9140:
--

seems good to me

> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8610) DIH - Resolve variables in encryptKeyFile

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-8610:
---
Attachment: SOLR-8610.patch

Seems fine, will commit it too. 

> DIH - Resolve variables in encryptKeyFile
> -
>
> Key: SOLR-8610
> URL: https://issues.apache.org/jira/browse/SOLR-8610
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8610.patch, SOLR-8610.patch
>
>
> I would like to use a variable like {{$\{path.to.file\}}} for  
> {{encryptKeyFile}} in my DIH config files so that I don't have to specify the 
> concrete absolute path in all files. This is currently not possible since 
> variables are not resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16904 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16904/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=92586, 
name=Thread-5412, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud]   
  at java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
 at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333) 
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
 at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
 at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
 at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)   
  at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:936) 
at org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2510)   
  at org.apache.solr.core.SolrCore$$Lambda$72/9556432.run(Unknown Source)   
  at org.apache.solr.cloud.ZkController$4.run(ZkController.java:2408)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 
   1) Thread[id=92586, name=Thread-5412, state=TIMED_WAITING, 
group=TGRP-TestSolrConfigHandlerCloud]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333)
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:936)
at 
org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2510)
at org.apache.solr.core.SolrCore$$Lambda$72/9556432.run(Unknown Source)
at org.apache.solr.cloud.ZkController$4.run(ZkController.java:2408)
at __randomizedtesting.SeedInfo.seed([C89159D162454B6C]:0)




Build Log:
[...truncated 12148 lines...]
   [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerCloud
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestSolrConfigHandlerCloud_C89159D162454B6C-001/init-core-data-001
   [junit4]   2> 1996140 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[C89159D162454B6C]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 1996141 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[C89159D162454B6C]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 1996143 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[C89159D162454B6C]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1996143 INFO  (Thread-5313) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1996144 INFO  (Thread-5313) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1996244 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[C89159D162454B6C]) [] 
o.a.s.c.ZkTestServer start zk server on port:35878
   [junit4]   2> 1996244 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[C89159D162454B6C]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1996245 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[C89159D162454B6C]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1996246 INFO  (zkCallback-23322-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@a97c9a name:ZooKeeperConnection 
Watcher:127.0.0.1:35878 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1996246 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[C89159D162454B6C]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1996246 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[C89159D162454B6C]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1996247 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[C89159D162454B6C]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 1996248 INFO  

[JENKINS] Lucene-Solr-Tests-master - Build # 1189 - Failure

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior

Error Message:
Illegal state, was: down expected:active clusterState:live 
nodes:[]collections:{c1=DocCollection(c1)={   "shards":{"shard1":{   
"parent":null,   "range":null,   "state":"active",   
"replicas":{"core_node1":{   "base_url":"http://127.0.0.1/solr;,
   "node_name":"node1",   "core":"core1",   "roles":"", 
  "state":"down",   "router":{"name":"implicit"}}, 
test=LazyCollectionRef(test)}

Stack Trace:
java.lang.AssertionError: Illegal state, was: down expected:active 
clusterState:live nodes:[]collections:{c1=DocCollection(c1)={
  "shards":{"shard1":{
  "parent":null,
  "range":null,
  "state":"active",
  "replicas":{"core_node1":{
  "base_url":"http://127.0.0.1/solr;,
  "node_name":"node1",
  "core":"core1",
  "roles":"",
  "state":"down",
  "router":{"name":"implicit"}}, test=LazyCollectionRef(test)}
at 
__randomizedtesting.SeedInfo.seed([CEC4632E0A269E2:64F245DE023233AC]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.verifyReplicaStatus(AbstractDistribZkTestBase.java:243)
at 
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior(OverseerTest.java:1273)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-8612) DIH JdbcDataSource - statement not always closed

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-8612:
---
Attachment: SOLR-8612.patch

removed *synchronized*, because I think they are redundant - DIH has no threads 
anymore.
Tests are perfect, and passed well. 
I'm going to commit it soon, maybe tomorrow.

> DIH JdbcDataSource - statement not always closed
> 
>
> Key: SOLR-8612
> URL: https://issues.apache.org/jira/browse/SOLR-8612
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.0
>
> Attachments: SOLR-8612.patch, SOLR-8612.patch, SOLR-8612.patch, 
> SOLR-8612.patch, SOLR-8612.patch
>
>
> There are several cases where the Statement used by JdbcDataSource is not 
> closed, potentially resulting in too many open connections:
> - an exception is throw in the {{ResultSetIterator}} constructor
> - the result set is null in the {{ResultSetIterator}} constructor
> - an exception is thrown during import and the import is aborted (onError 
> flag set to abort)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 247 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/247/

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([4DE70A0D02536C9B:3279BD886B314111]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:192)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:130)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay(ZkStateReaderTest.java:52)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11476 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest
   [junit4]   2> Creating dataDir: 

[jira] [Comment Edited] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[Hoss Man (JIRA)]

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

Hoss Man edited comment on SOLR-9107 at 6/2/16 6:36 PM:


FYI: the increased odds ot using SSL in nightly / with tests.multiplier have 
helped uncover some OOM issues in tests when using SSL, see SOLR-9182

(edit: typo in linked issue #)


was (Author: hossman):
FYI: the increased odds ot using SSL in nightly / with tests.multiplier have 
helped uncover some OOM issues in tests when using SSL, see SOLR-9180

> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9107:


FYI: the increased odds ot using SSL in nightly / with tests.multiplier have 
helped uncover some OOM issues in tests when using SSL, see SOLR-9180

> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9182) Test OOMs when ssl + clientAuth

[ASF subversion and git services (JIRA)]

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

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

Commit 7f821393690624e4d8db4bee45c0645785a72d73 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f82139 ]

SOLR-9182: SuppressSSL on some tests where it's non to cause OOM

(cherry picked from commit 1eb6c9f816fa09acf2d55370876f79218c0328c3)

Conflicts:

solr/core/src/test/org/apache/solr/cloud/TestTolerantUpdateProcessorRandomCloud.java


> Test OOMs when ssl + clientAuth
> ---
>
> Key: SOLR-9182
> URL: https://issues.apache.org/jira/browse/SOLR-9182
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> the combination of SOLR-9028 fixing SSLTestConfig to actually pay attention 
> to clientAuth setting, and SOLR-9107 increasing the odds of ssl+clientAuth 
> being tested has helped surface some more tests that seem to fairly 
> consistently trigger OOM when running with SSL+clientAuth.
> I'm not sure if there is some underlying memory leak somewhere in the SSL 
> code we're using, or if this is just a factor of increased request/response 
> size when using (double) encrypted requests, but for now I'm just focusing on 
> opening a tracking issue for them and suppressing SSL in these cases with a 
> link here to clarify *why* we're suppressing SSL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9182) Test OOMs when ssl + clientAuth

[ASF subversion and git services (JIRA)]

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

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

Commit 1eb6c9f816fa09acf2d55370876f79218c0328c3 in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1eb6c9f ]

SOLR-9182: SuppressSSL on some tests where it's non to cause OOM


> Test OOMs when ssl + clientAuth
> ---
>
> Key: SOLR-9182
> URL: https://issues.apache.org/jira/browse/SOLR-9182
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> the combination of SOLR-9028 fixing SSLTestConfig to actually pay attention 
> to clientAuth setting, and SOLR-9107 increasing the odds of ssl+clientAuth 
> being tested has helped surface some more tests that seem to fairly 
> consistently trigger OOM when running with SSL+clientAuth.
> I'm not sure if there is some underlying memory leak somewhere in the SSL 
> code we're using, or if this is just a factor of increased request/response 
> size when using (double) encrypted requests, but for now I'm just focusing on 
> opening a tracking issue for them and suppressing SSL in these cases with a 
> link here to clarify *why* we're suppressing SSL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9182) Test OOMs when ssl + clientAuth

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9182:


SOLR-9061 & SOLR-9062 are examples of other test that have had OOMs that 
surface specifically when testing with SSL (TestDistributedSearch, 
TestDistributedStatsComponentCardinality)



> Test OOMs when ssl + clientAuth
> ---
>
> Key: SOLR-9182
> URL: https://issues.apache.org/jira/browse/SOLR-9182
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> the combination of SOLR-9028 fixing SSLTestConfig to actually pay attention 
> to clientAuth setting, and SOLR-9107 increasing the odds of ssl+clientAuth 
> being tested has helped surface some more tests that seem to fairly 
> consistently trigger OOM when running with SSL+clientAuth.
> I'm not sure if there is some underlying memory leak somewhere in the SSL 
> code we're using, or if this is just a factor of increased request/response 
> size when using (double) encrypted requests, but for now I'm just focusing on 
> opening a tracking issue for them and suppressing SSL in these cases with a 
> link here to clarify *why* we're suppressing SSL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9182) Test OOMs when ssl + clientAuth

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9182:



Examples of problematic (and in most cases reliably reproducible) tests/seeds 
from Jenkins that cause OOM (when ssl & clientAuth are both randomized to true) 
on master at (or just after) 09372acb660d21b6da01f6ea65f00493126ee32b ...

{noformat}
ant test  -Dtestcase=DistribCursorPagingTest -Dtests.method=test 
-Dtests.seed=62CECCCFAC00A40C -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=es-EC -Dtests.timezone=Africa/Kampala -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

ant test  -Dtestcase=DistribCursorPagingTest -Dtests.method=test 
-Dtests.seed=D0C25AD7E00EA301 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=nl-SR -Dtests.timezone=Asia/Kashgar -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

ant test  -Dtestcase=DistributedIntervalFacetingTest -Dtests.method=test 
-Dtests.seed=D6FFED8B897EFCF1 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=vi-VN -Dtests.timezone=America/Argentina/San_Juan 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

ant test  -Dtestcase=DistributedIntervalFacetingTest -Dtests.method=test 
-Dtests.seed=12CAAD932EBCED92 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=hr-HR -Dtests.timezone=Asia/Dili -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

ant test  -Dtestcase=TestTolerantUpdateProcessorRandomCloud 
-Dtests.method=testRandomUpdates -Dtests.seed=DDDEE8990E59AD3C 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=da 
-Dtests.timezone=Australia/Adelaide -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

ant test  -Dtestcase=TestTolerantUpdateProcessorRandomCloud 
-Dtests.method=testSanityRandomUnsetBit -Dtests.seed=55D5DE5250D643CB 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/x1/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=es-DO -Dtests.timezone=America/Guatemala -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
 ... note: jenkins hit this, but it didn't reproduce for me
{noformat}

I'll move forward with adding {{@SuppressSSL}} to each of these tests linking 
back to this jira.
If anyone wants to investigate this more, that can be replaced with 
{{@RandomizeSSL(1.0)}} to force both SSL + clientAuth usage.



> Test OOMs when ssl + clientAuth
> ---
>
> Key: SOLR-9182
> URL: https://issues.apache.org/jira/browse/SOLR-9182
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> the combination of SOLR-9028 fixing SSLTestConfig to actually pay attention 
> to clientAuth setting, and SOLR-9107 increasing the odds of ssl+clientAuth 
> being tested has helped surface some more tests that seem to fairly 
> consistently trigger OOM when running with SSL+clientAuth.
> I'm not sure if there is some underlying memory leak somewhere in the SSL 
> code we're using, or if this is just a factor of increased request/response 
> size when using (double) encrypted requests, but for now I'm just focusing on 
> opening a tracking issue for them and suppressing SSL in these cases with a 
> link here to clarify *why* we're suppressing SSL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9182) Test OOMs when ssl + clientAuth

[Hoss Man (JIRA)]

Hoss Man created SOLR-9182:
--

 Summary: Test OOMs when ssl + clientAuth
 Key: SOLR-9182
 URL: https://issues.apache.org/jira/browse/SOLR-9182
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man



the combination of SOLR-9028 fixing SSLTestConfig to actually pay attention to 
clientAuth setting, and SOLR-9107 increasing the odds of ssl+clientAuth being 
tested has helped surface some more tests that seem to fairly consistently 
trigger OOM when running with SSL+clientAuth.

I'm not sure if there is some underlying memory leak somewhere in the SSL code 
we're using, or if this is just a factor of increased request/response size 
when using (double) encrypted requests, but for now I'm just focusing on 
opening a tracking issue for them and suppressing SSL in these cases with a 
link here to clarify *why* we're suppressing SSL.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7374:
---

I'm going to steal this issue ;)

> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Mark Miller
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-7374:
-

Assignee: Mark Miller  (was: Varun Thacker)

> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Mark Miller
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6237) An option to have only leaders write and replicas read when using a shared file system with SolrCloud.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-6237:
--
Attachment: 0001-unified.patch

Here is a patch demonstrating the approach I'm taking.

It's a bit stale compared to my current working state, but in trying to fix the 
leader promotion phase, I've walked back a few things as much as I've walked 
others forward.

This shows the basic idea though.

* Only the leader writes to the index or tlog, the replicas are in read only 
mode.
* Data dirs are published in ZK so that replicas can use the same location as 
leaders - this requires some juggling of init logic on startup.
* We have to be careful not to use a Writer when reopening a Reader - hard 
commits will control visibility in this mode as well, not soft commits.
* Realtime get is forwarded from replicas to the leader - non leaders can't 
serve them.
* Split shard and migrate and the like may need some additional work to operate 
correct.
* There are still issue around index locking I need to clear up.
* There are still some problems I'm working through on leader promotion 
involving seeing a corrupt view of the index.
* More tests are needed.

> An option to have only leaders write and replicas read when using a shared 
> file system with SolrCloud.
> --
>
> Key: SOLR-6237
> URL: https://issues.apache.org/jira/browse/SOLR-6237
> Project: Solr
>  Issue Type: New Feature
>  Components: hdfs, SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: 0001-unified.patch, Unified Replication Design.pdf
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16897 - Still Failing!

[Chris Hostetter]

FYI: this failure, and a handful of other (master) failures from teh past 
~20 hours seem to be OOMs due to SSL testing -- yesterday I 
commited SOLR-9107 which increased the *odds* that a given test run would 
use SSL (but didn't otherwise change anything about how SSL was used once 
the test started), and this seems to have accelerated finding some tests 
where the amount of data that needs encrypted is resulting in using up 
more heap then our tests are currently allowed to use.

Ie: these tests would likely fail anytime SSL is used, but i increased the 
odds that a given seed would result in SSL being used.

I'll file a new distinct issue regarding SSL usage and OOM, and start 
disabling SSL on the affected tests before backporting SOLR-9107 to 
branch_6x.



: Date: Thu, 2 Jun 2016 05:00:39 + (UTC)
: From: Policeman Jenkins Server 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build #
: 16897 - Still Failing!
: 
: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16897/
: Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC
: 
: 2 tests failed.
: FAILED:  org.apache.solr.cloud.DistribCursorPagingTest.test
: 
: Error Message:
: Java heap space
: 
: Stack Trace:
: java.lang.OutOfMemoryError: Java heap space
:   at 
__randomizedtesting.SeedInfo.seed([DDDEE8990E59AD3C:558AD743A0A5C0C4]:0)
:   at sun.security.ssl.InputRecord.(InputRecord.java:93)
:   at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
:   at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
:   at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
:   at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
:   at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
:   at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
:   at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
:   at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
:   at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
:   at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
:   at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
:   at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
:   at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
:   at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
:   at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
:   at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
:   at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
:   at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
:   at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
:   at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
:   at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.indexDoc(AbstractFullDistribZkTestBase.java:775)
:   at 
org.apache.solr.cloud.DistribCursorPagingTest.doRandomSortsOnLargeIndex(DistribCursorPagingTest.java:582)
:   at 
org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:94)
:   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:1764)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
: 
: 
: FAILED:  
org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud.testRandomUpdates
: 
: Error Message:
: Could not load collection from ZK: test_col
: 
: Stack Trace:
: org.apache.solr.common.SolrException: Could not load collection from ZK: 
test_col
:   at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1047)
:   at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:610)
:   at 

[jira] [Commented] (SOLR-9120) Luke NoSuchFileException

[Thomas Kurz (JIRA)]

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

Thomas Kurz commented on SOLR-9120:
---

We are running Solr 5.5.0, so it would be great to also put the fix on this.

> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
> Fix For: 6.1, master (7.0)
>
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9120) Luke NoSuchFileException

[Thomas Kurz (JIRA)]

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

Thomas Kurz commented on SOLR-9120:
---

Same here. This does not seem to break other parts but produces a lot of log 
noise and seems also to block the admin cores interface. Any ideas how to fix 
or workaround this?

> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
> Fix For: 6.1, master (7.0)
>
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: 

[jira] [Commented] (LUCENE-7314) Graduate InetAddressPoint and LatLonPoint to core

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7314:


+1 for graduating from sandbox but how about {{LatLonPoint}} and corresponding 
queries to a package in the {{spatial}} module? This is what we did for 
{{GeoPointField}} since its spatial specific and dependency free.

> Graduate InetAddressPoint and LatLonPoint to core
> -
>
> Key: LUCENE-7314
> URL: https://issues.apache.org/jira/browse/LUCENE-7314
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
>
> Maybe we should graduate these fields (and related queries) to core for 
> Lucene 6.1?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7314) Graduate InetAddressPoint and LatLonPoint to core

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7314:


+1

> Graduate InetAddressPoint and LatLonPoint to core
> -
>
> Key: LUCENE-7314
> URL: https://issues.apache.org/jira/browse/LUCENE-7314
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
>
> Maybe we should graduate these fields (and related queries) to core for 
> Lucene 6.1?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7312:


OK indeed this is a double precision issue ... I boiled it down to this small 
test:

{noformat}
  public void testOneValue() throws Exception {
double DECODE = 4.661822942981865E-10;
double x = -0.31622436580292346;
int xEnc = (int) Math.floor(x / DECODE);  // -678327705
double xDec = xEnc * DECODE;
// because we floor'd on encoding to xEnc, this should be true:
assertTrue("x=" + x + " xDec=" + xDec, xDec <= x);
  }
{noformat}

which fails with this:

{noformat}
  java.lang.AssertionError: x=-0.31622436580292346 xDec=-0.3162243658029234
{noformat}

The reason is that the value {{x / DECODE}} is very, very close to an
integer value, just a hair below it, such that when quantized, it
jumps just a bit above that int value, causing the floor to return the
"wrong" value.

You can also see it with Python's rational number module ({{fractions}}) too:

{noformat}
>>> DECODE = fractions.Fraction(4.661822942981865E-10)
>>> x = fractions.Fraction(-0.31622436580292346)
>>> math.floor(x / DECODE)
-678327706
>>> math.floor(float(x / DECODE))
-678327705
{noformat}

I.e. the true floor in this case is -678327706, but if you first
quantize to 64 bits and take the floor, you get one higher.

I think we should go back to the "safe" doubles solution we used to
have, where {{DECODE}} is the next higher double that doesn't use any of
its lower 32 bits.

I'll also port over a nice 2D test Rob pointed me to, which should be
more efficient for finding quantization issues.


> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7887:


I suspect that the log4j project would say that hadoop is using log4j 
incorrectly.

My gut reaction is that a HADOOP- issue needs to be filed, but I do not 
want to do that without discussing it with them first.  I am a member of far 
too many mailing lists already, but I may need to temporarily acquire another 
one.


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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9140) Replace some state polling with CollectionStateWatchers

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9140:

Attachment: SOLR-9140.patch

Updated patch.  This also seems to fix the occasional failures in 
TestCollectionStateWatchers where a node never properly comes up.

The original patch replaced some polling in the 'delete collection' handling 
part of OverseerCollectionMessageProcessor, but that caused some test failures 
where the client that was issuing the delete didn't get its collection state 
updated quickly enough and so was checking stale state.  One way round this 
might be to make the list-collection command go via the Overseer, so that it 
always gets the latest state, but that's for another issue.  For now I've just 
not included that change.

> Replace some state polling with CollectionStateWatchers
> ---
>
> Key: SOLR-9140
> URL: https://issues.apache.org/jira/browse/SOLR-9140
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: SOLR-9140.patch, SOLR-9140.patch
>
>
> There are a few places in ZkController and the collection processing code 
> that directly query ZK for collection state, and then wait and poll for 
> expected state changes.  We can now replace these with 
> CollectionStateWatchers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7314) Graduate InetAddressPoint and LatLonPoint to core

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7314:


 Summary: Graduate InetAddressPoint and LatLonPoint to core
 Key: LUCENE-7314
 URL: https://issues.apache.org/jira/browse/LUCENE-7314
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


Maybe we should graduate these fields (and related queries) to core for Lucene 
6.1?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7313) Remove DocValuesDocIdSet

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7313:


 Summary: Remove DocValuesDocIdSet
 Key: LUCENE-7313
 URL: https://issues.apache.org/jira/browse/LUCENE-7313
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor


This class is unused since we migrated the doc values filters to queries with 
two-phase iteration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7246) Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7246:
--

bq. Another possibility is having the LRUQueryCache not actually cache on the 
first hit, requiring a 2nd hit?

The cache already requires a second hit for point queries. I guess the 
frustration is about the fact that since these queries need to execute on the 
whole index, we want to cache them quite early, but then we have the issue that 
the action of creating a cache entry is not cheap, and can make things 
unnecessarily slower in the case that most ranges are used eg. eg. 2 or 3 
times. I don't think it is a big deal if we still do this copy for point 
queries, but I was curious to open this issue for discussion to see if we could 
find a clean way.

bq. In your patch LRUCache assumes whatever DocIdSet this returns is suitable 
to be cached.

Agreed it is not obvious. Now that Filter is gone, maybe we should update the 
DocIdSet javadocs in order to be explicit about the fact that DocIdSets need to 
be cacheable (there is no reason anymore to write non-cacheable doc id sets?). 
And maybe also add cacheable to the method name as you suggest.


> Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?
> --
>
> Key: LUCENE-7246
> URL: https://issues.apache.org/jira/browse/LUCENE-7246
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7246.patch, LUCENE-7246.patch
>
>
> Some queries need to create a DocIdSet to work. This is for instance the case 
> with TermsQuery, multi-term queries, point-in-set queries and point range 
> queries. We cache them more aggressively because these queries need to 
> evaluate all matches on a segment before they can return a Scorer. But this 
> can also be dangerous: if there is little reuse, then we keep converting the 
> doc id sets that these queries create to another DocIdSet.
> This worries me a bit eg. for point range queries: they made numeric ranges 
> faster in practice so I would not like caching to make them appear slower 
> than they are when caching is disabled.
> So I would like to somehow bring back the optimization that we had in 1.x 
> with DocIdSet.isCacheable so that we do not need to convert DocIdSet 
> instances when we could just reuse existing instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8787) TestAuthenticationFramework should not extend TestMiniSolrCloudCluster

[Trey Cahill (JIRA)]

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

Trey Cahill commented on SOLR-8787:
---

Added patch, which changes TestAuthenticationFramework to extend LuceneTestCase 
and not TestMiniSolrCloudCluster.  Used functions from 
TestMiniSolrCloudCluster, but removed any non-needed operations/etc.

> TestAuthenticationFramework should not extend TestMiniSolrCloudCluster
> --
>
> Key: SOLR-8787
> URL: https://issues.apache.org/jira/browse/SOLR-8787
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 6.0, 6.1
>
> Attachments: SOLR-8787.patch
>
>
> TestAuthenticationFramework should not extend TestMiniSolrCloudCluster. The 
> TestMiniSolrCloudCluster is actually a test for MiniSolrCloudCluster and not 
> a generic test framework class. I saw a local failure for 
> TestAuthenticationFramework.testSegmentTerminateEarly which should never be 
> executed in the first place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8787) TestAuthenticationFramework should not extend TestMiniSolrCloudCluster

[Trey Cahill (JIRA)]

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

Trey Cahill updated SOLR-8787:
--
Attachment: SOLR-8787.patch

> TestAuthenticationFramework should not extend TestMiniSolrCloudCluster
> --
>
> Key: SOLR-8787
> URL: https://issues.apache.org/jira/browse/SOLR-8787
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: difficulty-easy, newdev
> Fix For: 6.0, 6.1
>
> Attachments: SOLR-8787.patch
>
>
> TestAuthenticationFramework should not extend TestMiniSolrCloudCluster. The 
> TestMiniSolrCloudCluster is actually a test for MiniSolrCloudCluster and not 
> a generic test framework class. I saw a local failure for 
> TestAuthenticationFramework.testSegmentTerminateEarly which should never be 
> executed in the first place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7246) Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7246:
--

Another possibility is having the LRUQueryCache not actually cache on the first 
hit, requiring a 2nd hit?  That obviously has its trade-offs too.  I guess I 
kind of like this patch better than doing that, even if it adds a new API 
method on Weight.  But it does intertwine two things -- returning a DocIdSet, 
and wether or not this DocIdSet should be cached.  In your patch LRUCache 
assumes whatever DocIdSet this returns is suitable to be cached.  Maybe it is 
sometimes but not other times?  We could just override this method for the ones 
where it is cacheable but, again, we're then intertwining concerns.  Maybe 
DocIdSet should have an isCacheable(), so that if it isn't _then_ we wrap in a 
RoardingDocIdSet.  Or if we really don't want that method, then have this new 
method on Weight be named something like cacheableDocIdSet.  Then it's clear 
that the method should only be overridden when the Query/Weight already has one 
(e.g. a bit set).

> Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?
> --
>
> Key: LUCENE-7246
> URL: https://issues.apache.org/jira/browse/LUCENE-7246
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7246.patch, LUCENE-7246.patch
>
>
> Some queries need to create a DocIdSet to work. This is for instance the case 
> with TermsQuery, multi-term queries, point-in-set queries and point range 
> queries. We cache them more aggressively because these queries need to 
> evaluate all matches on a segment before they can return a Scorer. But this 
> can also be dangerous: if there is little reuse, then we keep converting the 
> doc id sets that these queries create to another DocIdSet.
> This worries me a bit eg. for point range queries: they made numeric ranges 
> faster in practice so I would not like caching to make them appear slower 
> than they are when caching is disabled.
> So I would like to somehow bring back the optimization that we had in 1.x 
> with DocIdSet.isCacheable so that we do not need to convert DocIdSet 
> instances when we could just reuse existing instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7312:
-

How odd... I don't know why this would be, but it seems like maybe we have to 
dump the numbers in question as hex values in order to see what is in fact 
happening?

> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7246) Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7246:
--

Yep, exactly.

> Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?
> --
>
> Key: LUCENE-7246
> URL: https://issues.apache.org/jira/browse/LUCENE-7246
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7246.patch, LUCENE-7246.patch
>
>
> Some queries need to create a DocIdSet to work. This is for instance the case 
> with TermsQuery, multi-term queries, point-in-set queries and point range 
> queries. We cache them more aggressively because these queries need to 
> evaluate all matches on a segment before they can return a Scorer. But this 
> can also be dangerous: if there is little reuse, then we keep converting the 
> doc id sets that these queries create to another DocIdSet.
> This worries me a bit eg. for point range queries: they made numeric ranges 
> faster in practice so I would not like caching to make them appear slower 
> than they are when caching is disabled.
> So I would like to somehow bring back the optimization that we had in 1.x 
> with DocIdSet.isCacheable so that we do not need to convert DocIdSet 
> instances when we could just reuse existing instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7246) Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7246:
--

So is this trying to avoid a needless conversion to a RoaringDocIdSet?

> Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?
> --
>
> Key: LUCENE-7246
> URL: https://issues.apache.org/jira/browse/LUCENE-7246
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7246.patch, LUCENE-7246.patch
>
>
> Some queries need to create a DocIdSet to work. This is for instance the case 
> with TermsQuery, multi-term queries, point-in-set queries and point range 
> queries. We cache them more aggressively because these queries need to 
> evaluate all matches on a segment before they can return a Scorer. But this 
> can also be dangerous: if there is little reuse, then we keep converting the 
> doc id sets that these queries create to another DocIdSet.
> This worries me a bit eg. for point range queries: they made numeric ranges 
> faster in practice so I would not like caching to make them appear slower 
> than they are when caching is disabled.
> So I would like to somehow bring back the optimization that we had in 1.x 
> with DocIdSet.isCacheable so that we do not need to convert DocIdSet 
> instances when we could just reuse existing instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7312:


The test just encodes and then decodes and checks that the decoded version 
indeed rounded down, yet for this particular value, for some reason, the {{Y}} 
dimension failed to round down:

{noformat}
   [junit4]   1> iter=2881 i=243 lat=-61.0001734 lon=-139.2156822602591
   [junit4]   1>   point=[lat=-1.0646508437165714, 
lon=-2.4297720258517823([X=-0.36655223771437473, Y=-0.31622436580292346, 
Z=-0.8733499201429061])]
   [junit4]   1>   pointEnc=[X=-0.3665522380425261, Y=-0.3162243658029234, 
Z=-0.8733499202383181]
{noformat}

> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7312:


Hmm I'll dig ...

> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9181) ZkStateReaderTest failure

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9181:

Attachment: SOLR-9181.patch

Patch.  This also uncovered a couple of bugs in the collection state watcher 
API to do with collections in state format 1:
* format-1-collections wouldn't trigger notifications on updates if they hadn't 
already been registered
* registering a watcher on a format-1 collection wouldn't check the current 
state if the collection wasn't already watched

> ZkStateReaderTest failure
> -
>
> Key: SOLR-9181
> URL: https://issues.apache.org/jira/browse/SOLR-9181
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9181.patch
>
>
> https://builds.apache.org/job/Lucene-Solr-Tests-6.x/243/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 224 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/224/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.analysis.pt.TestPortugueseLightStemFilter

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001\tempDir-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001\tempDir-001

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001\tempDir-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001\tempDir-001
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.pt.TestPortugueseLightStemFilter_BA3FEBD67B83DE8C-001

at __randomizedtesting.SeedInfo.seed([BA3FEBD67B83DE8C]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:323)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 2586 lines...]
   [junit4] Suite: org.apache.lucene.analysis.pt.TestPortugueseLightStemFilter
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=ClassicSimilarity, locale=fr-LU, timezone=America/Argentina/Tucuman
   [junit4]   2> NOTE: Windows 10 10.0 x86/Oracle Corporation 1.8.0_92 
(32-bit)/cpus=3,threads=1,free=263896328,total=417333248
   [junit4]   2> NOTE: All tests run in this JVM: 
[TestGalicianMinimalStemFilterFactory, TestItalianAnalyzer, 
TestHyphenatedWordsFilter, TestComplexPrefix, TestSoraniStemFilterFactory, 
TestSwedishAnalyzer, TestCJKWidthFilter, TestPatternReplaceFilter, 
TestApostropheFilter, TestPatternReplaceFilterFactory, 
TestDecimalDigitFilterFactory, TestSerbianNormalizationFilter, 
TestBulgarianStemmer, TestSpanishAnalyzer, TestCatalanAnalyzer, 
TestHunspellStemFilter, TestSnowball, TestLengthFilter, 
TestLengthFilterFactory, TestTurkishLowerCaseFilter, TestElisionFilterFactory, 
TestSoraniAnalyzer, TestPortugueseMinimalStemFilterFactory, TestStopAnalyzer, 
TestDanishAnalyzer, TestUAX29URLEmailTokenizer, TestMultiWordSynonyms, 
TestLimitTokenCountFilterFactory, TestHindiNormalizer, TestMorphAlias, 
TestStemmerOverrideFilter, TestKeywordRepeatFilter, TestDoubleEscape, 
GreekAnalyzerTest, TestFullStrip, TestFrenchLightStemFilterFactory, 
TestIndicNormalizer, TestGalicianAnalyzer, TestFrenchMinimalStemFilter, 
TestSwedishLightStemFilter, TestElision, TestBrazilianStemFilterFactory, 
ShingleAnalyzerWrapperTest, TestDutchAnalyzer, 
TestGermanLightStemFilterFactory, TestScandinavianNormalizationFilter, 
TestPersianNormalizationFilter, TestWikipediaTokenizerFactory, 
TokenOffsetPayloadTokenFilterTest, TestHindiStemmer, TestTwoFold, 
TestEnglishAnalyzer, TestIndonesianAnalyzer, 

[jira] [Updated] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9081:

Attachment: SOLR-9081.patch

Lots of subclasses already have a public beforeClass() or afterClass(), so I 
just changed the names to setupTestCases and teardownTestCases().

I'll commit tomorrow, unless somebody objects.

> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with 
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Georg Sorst
>Assignee: Alan Woodward
>Priority: Blocker
> Attachments: SOLR-9081.patch
>
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
> currently defined as {{private static void}}. This causes problems with 
> Mockito, which requires all test framework methods (including 
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}. 
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
>   /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be 
> public}}
> The very trivial fix is to change both methods to {{public static void}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5886 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5886/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch

Error Message:
CollectionStateWatcher wasn't cleared after completion

Stack Trace:
java.lang.AssertionError: CollectionStateWatcher wasn't cleared after completion
at 
__randomizedtesting.SeedInfo.seed([BF0ADABEC5EA6A6B:E23115CE82E7F555]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch(TestCollectionStateWatchers.java:117)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 13044 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating dataDir: 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16901 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16901/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 4 object(s) that were not released!!! [TransactionLog, 
MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor]
at __randomizedtesting.SeedInfo.seed([F7212768FD2DDE10]: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.afterClass(SolrTestCaseJ4.java:258)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([F7212768FD2DDE10:7F7518B253D1B3E8]:0)
at sun.security.ssl.InputRecord.(InputRecord.java:93)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 

Re: Lucene/Solr 6.1.0

[Martijn v Groningen]

+1

On 2 June 2016 at 14:52, Joel Bernstein  wrote:

> +1
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Thu, Jun 2, 2016 at 7:09 AM, Uwe Schindler  wrote:
>
>> +1
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Adrien Grand [mailto:jpou...@gmail.com]
>> *Sent:* Thursday, June 02, 2016 8:55 AM
>> *To:* Lucene Dev 
>> *Subject:* Lucene/Solr 6.1.0
>>
>>
>>
>> I think it is time for a 6.1.0 release? 6.0.0 was released 2 months ago
>> and both Lucene and Solr accumulated an interesting list of
>> features/optimizations since then.
>>
>> I volunteer to be the release manager unless someone else wants to, and I
>> propose to create the 6.1 branch on June 8th and build the first RC on June
>> 10th. Let me know if that does not work for you.
>>
>> Adrien
>>
>
>


-- 
Met vriendelijke groet,

Martijn van Groningen

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 74 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/74/

No tests ran.

Build Log:
[...truncated 40524 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (12.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.1.0-src.tgz...
   [smoker] 28.7 MB in 0.02 sec (1201.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.1.0.tgz...
   [smoker] 63.0 MB in 0.05 sec (1199.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.1.0.zip...
   [smoker] 73.6 MB in 0.06 sec (1222.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 218 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (23.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.1.0-src.tgz...
   [smoker] 37.9 MB in 0.24 sec (157.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.1.0.tgz...
   [smoker] 132.4 MB in 1.65 sec (80.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.1.0.zip...
   [smoker] 141.0 MB in 1.78 sec (79.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.1.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]   [-]  
   

[jira] [Commented] (LUCENE-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[ASF subversion and git services (JIRA)]

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

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

Commit 50feae82af5d297b720a98db07ab43e093e788b8 in lucene-solr's branch 
refs/heads/branch_6x from [~martijn]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=50feae8 ]

LUCENE-7307: Add getters to the PointInSetQuery and PointRangeQuery queries.


> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE-7307, LUCENE_7307.patch, LUCENE_7307.patch, 
> LUCENE_7307.patch, LUCENE_7307.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7307: Add getters to the PointInSetQuery and PointRangeQuery queries.


> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE-7307, LUCENE_7307.patch, LUCENE_7307.patch, 
> LUCENE_7307.patch, LUCENE_7307.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Lucene/Solr 6.1.0

[Joel Bernstein]

+1

Joel Bernstein
http://joelsolr.blogspot.com/

On Thu, Jun 2, 2016 at 7:09 AM, Uwe Schindler  wrote:

> +1
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Adrien Grand [mailto:jpou...@gmail.com]
> *Sent:* Thursday, June 02, 2016 8:55 AM
> *To:* Lucene Dev 
> *Subject:* Lucene/Solr 6.1.0
>
>
>
> I think it is time for a 6.1.0 release? 6.0.0 was released 2 months ago
> and both Lucene and Solr accumulated an interesting list of
> features/optimizations since then.
>
> I volunteer to be the release manager unless someone else wants to, and I
> propose to create the 6.1 branch on June 8th and build the first RC on June
> 10th. Let me know if that does not work for you.
>
> Adrien
>

[jira] [Commented] (SOLR-9181) ZkStateReaderTest failure

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-9181:
-

This is a test bug, I think.  There's a race when a collection is migrated from 
state format 1 to state format 2, where the state reader may briefly see the 
collection removed from collectionstate.json before it sees the new 
collection/state.json znode.  The test fails to take that into account, and 
assumes that clusterState.getCollection() will always return a DocCollection 
object.  It can be fixed by using waitForState() instead of polling.  I'll put 
up a patch shortly.

> ZkStateReaderTest failure
> -
>
> Key: SOLR-9181
> URL: https://issues.apache.org/jira/browse/SOLR-9181
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>
> https://builds.apache.org/job/Lucene-Solr-Tests-6.x/243/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9181) ZkStateReaderTest failure

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-9181:
---

 Summary: ZkStateReaderTest failure
 Key: SOLR-9181
 URL: https://issues.apache.org/jira/browse/SOLR-9181
 Project: Solr
  Issue Type: Bug
Reporter: Alan Woodward
Assignee: Alan Woodward


https://builds.apache.org/job/Lucene-Solr-Tests-6.x/243/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+120) - Build # 808 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/808/
Java: 64bit/jdk-9-ea+120 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ObjectTracker found 4 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [SolrCore, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([B33CAC87DD7C0F45]: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.afterClass(SolrTestCaseJ4.java:256)
at jdk.internal.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=7800, name=searcherExecutor-3931-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.park(java.base@9-ea/LockSupport.java:190)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@9-ea/AbstractQueuedSynchronizer.java:2064)
 at 
java.util.concurrent.LinkedBlockingQueue.take(java.base@9-ea/LinkedBlockingQueue.java:442)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1083)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=7800, name=searcherExecutor-3931-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method)
at 
java.util.concurrent.locks.LockSupport.park(java.base@9-ea/LockSupport.java:190)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@9-ea/AbstractQueuedSynchronizer.java:2064)
at 
java.util.concurrent.LinkedBlockingQueue.take(java.base@9-ea/LinkedBlockingQueue.java:442)
at 

[jira] [Assigned] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito

[Alan Woodward (JIRA)]

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

Alan Woodward reassigned SOLR-9081:
---

Assignee: Alan Woodward

> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with 
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Georg Sorst
>Assignee: Alan Woodward
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
> currently defined as {{private static void}}. This causes problems with 
> Mockito, which requires all test framework methods (including 
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}. 
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
>   /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be 
> public}}
> The very trivial fix is to change both methods to {{public static void}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-9081:
-

Thanks Georg, this looks like a no-brainer to me.

> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with 
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Georg Sorst
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
> currently defined as {{private static void}}. This causes problems with 
> Mockito, which requires all test framework methods (including 
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}. 
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
>   /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be 
> public}}
> The very trivial fix is to change both methods to {{public static void}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/173/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val modified' for path 'response/params/y/c' 
full output: {   "responseHeader":{ "status":0, "QTime":0},   
"response":{ "znodeVersion":0, "params":{"x":{ "a":"A val", 
"b":"B val", "":{"v":0},  from server:  
http://127.0.0.1:49740/_v/s/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val modified' for 
path 'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":0,
"params":{"x":{
"a":"A val",
"b":"B val",
"":{"v":0},  from server:  http://127.0.0.1:49740/_v/s/collection1
at 
__randomizedtesting.SeedInfo.seed([68559E6C35022ED7:E001A1B69BFE432F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:195)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 81 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/81/

1 tests failed.
FAILED:  
org.apache.lucene.search.join.TestBlockJoin.testMultiChildQueriesOfDiffParentLevels

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:724)
at org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:1047)
at 
org.apache.lucene.index.RandomIndexWriter.addDocuments(RandomIndexWriter.java:199)
at 
org.apache.lucene.search.join.TestBlockJoin.testMultiChildQueriesOfDiffParentLevels(TestBlockJoin.java:1743)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.OutOfMemoryError: Java heap space
at org.apache.lucene.store.RAMFile.newBuffer(RAMFile.java:78)
at org.apache.lucene.store.RAMFile.addBuffer(RAMFile.java:51)
at 
org.apache.lucene.store.RAMOutputStream.switchCurrentBuffer(RAMOutputStream.java:164)
at 
org.apache.lucene.store.RAMOutputStream.writeBytes(RAMOutputStream.java:150)
at 
org.apache.lucene.store.MockIndexOutputWrapper.writeBytes(MockIndexOutputWrapper.java:141)
at 
org.apache.lucene.store.RateLimitedIndexOutput.writeBytes(RateLimitedIndexOutput.java:73)
at 

[jira] [Updated] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito

[Georg Sorst (JIRA)]

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

Georg Sorst updated SOLR-9081:
--
Affects Version/s: 5.5
   5.5.1

> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with 
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Georg Sorst
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
> currently defined as {{private static void}}. This causes problems with 
> Mockito, which requires all test framework methods (including 
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}. 
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
>   /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be 
> public}}
> The very trivial fix is to change both methods to {{public static void}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito

[Georg Sorst (JIRA)]

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

Georg Sorst updated SOLR-9081:
--
Affects Version/s: 6.0.1

> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with 
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 6.0, 6.0.1
>Reporter: Georg Sorst
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
> currently defined as {{private static void}}. This causes problems with 
> Mockito, which requires all test framework methods (including 
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}. 
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
>   /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be 
> public}}
> The very trivial fix is to change both methods to {{public static void}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: Lucene/Solr 6.1.0

[Uwe Schindler]

+1

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Adrien Grand [mailto:jpou...@gmail.com] 
Sent: Thursday, June 02, 2016 8:55 AM
To: Lucene Dev 
Subject: Lucene/Solr 6.1.0

 

I think it is time for a 6.1.0 release? 6.0.0 was released 2 months ago and 
both Lucene and Solr accumulated an interesting list of features/optimizations 
since then.

I volunteer to be the release manager unless someone else wants to, and I 
propose to create the 6.1 branch on June 8th and build the first RC on June 
10th. Let me know if that does not work for you.

Adrien

[jira] [Commented] (LUCENE-7312) Geo3dPoint test failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7312:
-

[~mikemccand]: This is reproducible, and it's your test.  Any comments?


> Geo3dPoint test failure
> ---
>
> Key: LUCENE-7312
> URL: https://issues.apache.org/jira/browse/LUCENE-7312
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Affects Versions: master (7.0)
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> Here's the failure:
> {code}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
> -Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7312) Geo3dPoint test failure

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7312:
---

 Summary: Geo3dPoint test failure
 Key: LUCENE-7312
 URL: https://issues.apache.org/jira/browse/LUCENE-7312
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial3d
Affects Versions: master (7.0)
Reporter: Karl Wright
Assignee: Karl Wright


Here's the failure:

{code}
ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testEncodeDecodeRoundsDown 
-Dtests.seed=7046405B94C1716E -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=da-DK -Dtests.timezone=America/Detroit -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 807 - Still Failing!

[Karl Wright]

Created LUCENE-7312 for this.

Karl


On Thu, Jun 2, 2016 at 5:51 AM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/807/
> Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC
>
> 1 tests failed.
> FAILED:
> org.apache.lucene.spatial3d.TestGeo3DPoint.testEncodeDecodeRoundsDown
>
> Error Message:
>
>
> Stack Trace:
> java.lang.AssertionError
> at
> __randomizedtesting.SeedInfo.seed([7046405B94C1716E:87357D43D1531E19]:0)
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at
> org.apache.lucene.spatial3d.TestGeo3DPoint.testEncodeDecodeRoundsDown(TestGeo3DPoint.java:1176)
> 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:1764)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
> 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:367)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
> 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:367)
> at java.lang.Thread.run(Thread.java:745)
>
>
>
>
> Build Log:
> [...truncated 8933 lines...]
>[junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
>[junit4] IGNOR/A 0.01s J1 | TestGeo3DPoint.testRandomBig
>[junit4]> Assumption #1: 'nightly' test group is disabled
> (@Nightly())
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint
> -Dtests.method=testEncodeDecodeRoundsDown 

[jira] [Commented] (LUCENE-7276) Add an optional reason to the MatchNoDocsQuery

[Christoph Buescher (JIRA)]

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

Christoph Buescher commented on LUCENE-7276:


+1

> Add an optional reason to the MatchNoDocsQuery
> --
>
> Key: LUCENE-7276
> URL: https://issues.apache.org/jira/browse/LUCENE-7276
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Ferenczi Jim
>Priority: Minor
>  Labels: patch
> Attachments: LUCENE-7276.patch
>
>
> It's sometimes difficult to debug a query that results in a MatchNoDocsQuery. 
> The MatchNoDocsQuery is always rewritten in an empty boolean query.
> This patch adds an optional reason and implements a weight in order to keep 
> track of the reason why the query did not match any document. The reason is 
> printed on toString and when an explanation for noMatch is asked.  
> For instance the query:
> new MatchNoDocsQuery("Field not found").toString()
> => 'MatchNoDocsQuery["field 'title' not found"]'



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7276) Add an optional reason to the MatchNoDocsQuery

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7276:
---

+1

> Add an optional reason to the MatchNoDocsQuery
> --
>
> Key: LUCENE-7276
> URL: https://issues.apache.org/jira/browse/LUCENE-7276
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Ferenczi Jim
>Priority: Minor
>  Labels: patch
> Attachments: LUCENE-7276.patch
>
>
> It's sometimes difficult to debug a query that results in a MatchNoDocsQuery. 
> The MatchNoDocsQuery is always rewritten in an empty boolean query.
> This patch adds an optional reason and implements a weight in order to keep 
> track of the reason why the query did not match any document. The reason is 
> printed on toString and when an explanation for noMatch is asked.  
> For instance the query:
> new MatchNoDocsQuery("Field not found").toString()
> => 'MatchNoDocsQuery["field 'title' not found"]'



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 807 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/807/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testEncodeDecodeRoundsDown

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([7046405B94C1716E:87357D43D1531E19]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testEncodeDecodeRoundsDown(TestGeo3DPoint.java:1176)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 8933 lines...]
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4] IGNOR/A 0.01s J1 | TestGeo3DPoint.testRandomBig
   [junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
-Dtests.method=testEncodeDecodeRoundsDown -Dtests.seed=7046405B94C1716E 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=da-DK 
-Dtests.timezone=America/Detroit -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 2.22s J1 | TestGeo3DPoint.testEncodeDecodeRoundsDown <<<
   [junit4]> Throwable #1: 

Re: Lucene/Solr 6.1.0

[Michael McCandless]

+1

Thanks for volunteering Adrien!

Mike McCandless

http://blog.mikemccandless.com

On Thu, Jun 2, 2016 at 2:54 AM, Adrien Grand  wrote:

> I think it is time for a 6.1.0 release? 6.0.0 was released 2 months ago
> and both Lucene and Solr accumulated an interesting list of
> features/optimizations since then.
>
> I volunteer to be the release manager unless someone else wants to, and I
> propose to create the 6.1 branch on June 8th and build the first RC on June
> 10th. Let me know if that does not work for you.
>
> Adrien
>

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16899/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.DistributedIntervalFacetingTest.test

Error Message:
Error from server at https://127.0.0.1:33138//collection1: Error from server at 
https://127.0.0.1:33138//collection1: Expected mime type 
application/octet-stream but got text/html.Error 
500HTTP ERROR: 500 Problem accessing 
/collection1/select. Reason: java.lang.OutOfMemoryError: Java heap 
space http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314   

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:33138//collection1: Error from server at 
https://127.0.0.1:33138//collection1: Expected mime type 
application/octet-stream but got text/html. 


Error 500 


HTTP ERROR: 500
Problem accessing /collection1/select. Reason:
java.lang.OutOfMemoryError: Java heap space
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314



at 
__randomizedtesting.SeedInfo.seed([D6FFED8B897EFCF1:5EABD25127829109]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:557)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:605)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:574)
at 
org.apache.solr.DistributedIntervalFacetingTest.doTestQuery(DistributedIntervalFacetingTest.java:190)
at 
org.apache.solr.DistributedIntervalFacetingTest.testRandom(DistributedIntervalFacetingTest.java:159)
at 
org.apache.solr.DistributedIntervalFacetingTest.test(DistributedIntervalFacetingTest.java:45)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1011)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-8744) Overseer operations need more fine grained mutual exclusion

[ASF subversion and git services (JIRA)]

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

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

Commit 734dcb99fcdd557ef046166193ae804824023db3 in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=734dcb9 ]

SOLR-8744: Overseer operations performed with fine grained mutual exclusion


> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>  Labels: sharding, solrcloud
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, 
> SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this 
> is a big scaling problem.  Multiple split shard operations could happen at 
> the time time, as long as different shards are being split.  In practice, 
> those shards often reside on different machines, so there's no I/O bottleneck 
> in those cases, just the mutex in Overseer forcing the operations to be done 
> serially.
> Given that a single split can take many minutes on a large collection, this 
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need 
> exclusive access at various levels. Each operation must define the Access 
> level at which the access is required. Access level is an enum. 
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look 
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend: 
> C1, C2 -> Collections
> S1, S2 -> Shards 
> R1,R2,R3,R4 -> Replicas
>  Cluster
> /   \
>/ \ 
>   C1  C2
>  / \ /   \ 
> /   \   / \  
>S1   S2  S1 S2
> R1, R2  R3.R4  R1,R2   R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate 
> lock from the tree. For example, if an operation needs a lock at a Collection 
> level and it needs to operate on Collection C1, the node C1 and all child 
> nodes of C1 must be free. 
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and 
> start moving down depending upon the operation. After it reaches the right 
> node, it checks if all the children are free from a lock.  If it fails to 
> acquire a lock, it remains in the work queue. A scheduler thread waits for 
> notification from the current set of tasks . Every task would do a 
> {{notify()}} on the monitor of  the scheduler thread. The thread would start 
> from the head of the queue and check all tasks to see if that task is able to 
> acquire the right lock. If yes, it is executed, if not, the task is left in 
> the work queue.  
> When a new task arrives in the work queue, the schedulerthread wakes and just 
> try to schedule that task.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8744) Overseer operations need more fine grained mutual exclusion

[ASF subversion and git services (JIRA)]

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

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

Commit 459a9c77a6a9b807deb98c58225d4d0ec1f75bac in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=459a9c7 ]

SOLR-8744: Overseer operations performed with fine grained mutual exclusion


> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>  Labels: sharding, solrcloud
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, 
> SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this 
> is a big scaling problem.  Multiple split shard operations could happen at 
> the time time, as long as different shards are being split.  In practice, 
> those shards often reside on different machines, so there's no I/O bottleneck 
> in those cases, just the mutex in Overseer forcing the operations to be done 
> serially.
> Given that a single split can take many minutes on a large collection, this 
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need 
> exclusive access at various levels. Each operation must define the Access 
> level at which the access is required. Access level is an enum. 
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look 
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend: 
> C1, C2 -> Collections
> S1, S2 -> Shards 
> R1,R2,R3,R4 -> Replicas
>  Cluster
> /   \
>/ \ 
>   C1  C2
>  / \ /   \ 
> /   \   / \  
>S1   S2  S1 S2
> R1, R2  R3.R4  R1,R2   R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate 
> lock from the tree. For example, if an operation needs a lock at a Collection 
> level and it needs to operate on Collection C1, the node C1 and all child 
> nodes of C1 must be free. 
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and 
> start moving down depending upon the operation. After it reaches the right 
> node, it checks if all the children are free from a lock.  If it fails to 
> acquire a lock, it remains in the work queue. A scheduler thread waits for 
> notification from the current set of tasks . Every task would do a 
> {{notify()}} on the monitor of  the scheduler thread. The thread would start 
> from the head of the queue and check all tasks to see if that task is able to 
> acquire the right lock. If yes, it is executed, if not, the task is left in 
> the work queue.  
> When a new task arrives in the work queue, the schedulerthread wakes and just 
> try to schedule that task.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7311) TermWeight shoud seek terms lazily

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7311:
--

+1 the patch was a bit trappy to write so I agree we should look at simplifying 
things first

> TermWeight shoud seek terms lazily
> --
>
> Key: LUCENE-7311
> URL: https://issues.apache.org/jira/browse/LUCENE-7311
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7311.patch
>
>
> Currently the terms are seeked eagerly in TermQuery.createWeight when 
> creating the TermContext. This might be wasteful when scores are not needed 
> since the query might be cached on some segments, thus seeking the term on 
> these segments is not needed. We could change TermWeight to only seek terms 
> in Weight.scorer when scores are not needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7246) Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7246:
-
Attachment: LUCENE-7246.patch

Here is a prototype that adds the logic to Weight rather than DISI.

> Can LRUQueryCache reuse DocIdSets that are created by some queries anyway?
> --
>
> Key: LUCENE-7246
> URL: https://issues.apache.org/jira/browse/LUCENE-7246
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7246.patch, LUCENE-7246.patch
>
>
> Some queries need to create a DocIdSet to work. This is for instance the case 
> with TermsQuery, multi-term queries, point-in-set queries and point range 
> queries. We cache them more aggressively because these queries need to 
> evaluate all matches on a segment before they can return a Scorer. But this 
> can also be dangerous: if there is little reuse, then we keep converting the 
> doc id sets that these queries create to another DocIdSet.
> This worries me a bit eg. for point range queries: they made numeric ranges 
> faster in practice so I would not like caching to make them appear slower 
> than they are when caching is disabled.
> So I would like to somehow bring back the optimization that we had in 1.x 
> with DocIdSet.isCacheable so that we do not need to convert DocIdSet 
> instances when we could just reuse existing instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7311) TermWeight shoud seek terms lazily

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7311:
-

Well, i personally think TermQuery/TermWeight should be very easy to follow and 
understand. If its not: there is no hope for any of our other queries.

I don't think we should explicitly optimize for abusive cases here, potentially 
causing bugs and making the code impossible to work with.

If we can simplify/redesign Weight so that this stuff is more natural, then I 
think thats fine, but I think there are too many special cases in the code 
already.

Some of these special cases might be easy to fix, just by doing some janitorial 
work. e.g. what is TermContext.hasOnlyRealTerms()? Do we still need this, is 
only to support autoprefix? Should we just remove autoprefix and these apis now 
that we have points? 

> TermWeight shoud seek terms lazily
> --
>
> Key: LUCENE-7311
> URL: https://issues.apache.org/jira/browse/LUCENE-7311
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7311.patch
>
>
> Currently the terms are seeked eagerly in TermQuery.createWeight when 
> creating the TermContext. This might be wasteful when scores are not needed 
> since the query might be cached on some segments, thus seeking the term on 
> these segments is not needed. We could change TermWeight to only seek terms 
> in Weight.scorer when scores are not needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7311) TermWeight shoud seek terms lazily

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7311:
--

I agree I am not much of a fan either, but opened this issue for discussion 
since it is something that I have seen a couple times already with users who 
have (very) large boolean filters that get reused. Another way to address these 
use-cases would be to have a tiny TermState cache on top of the terms 
dictionary, this way this optimization would be decoupled from the Weight 
implementations (the patch addresses TermQuery but it affects all queries that 
work on top of terms, like eg. phrase queries).

Removing queryNorm is appealing regardless of this change. :)

> TermWeight shoud seek terms lazily
> --
>
> Key: LUCENE-7311
> URL: https://issues.apache.org/jira/browse/LUCENE-7311
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7311.patch
>
>
> Currently the terms are seeked eagerly in TermQuery.createWeight when 
> creating the TermContext. This might be wasteful when scores are not needed 
> since the query might be cached on some segments, thus seeking the term on 
> these segments is not needed. We could change TermWeight to only seek terms 
> in Weight.scorer when scores are not needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 181 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/181/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Error from server at http://127.0.0.1:56967/solr/collection1: Expected mime 
type application/octet-stream but got text/html.Error 
500HTTP ERROR: 500 Problem accessing 
/solr/collection1/update. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.xml.sax.SAXParseException},msg=SolrCore
 collection1 is not available due to init failure: Could not load 
conf for core collection1: Cant load schema 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_9C8587AC75677094-001/solr-instance-028/collection1/conf/schema.xml:
 org.xml.sax.SAXParseException; systemId: solrres:/schema.xml; lineNumber: 1; 
columnNumber: 1; Final de archivo 
prematuro.,trace=org.apache.solr.common.SolrException: SolrCore 
collection1 is not available due to init failure: Could not load 
conf for core collection1: Cant load schema 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_9C8587AC75677094-001/solr-instance-028/collection1/conf/schema.xml:
 org.xml.sax.SAXParseException; systemId: solrres:/schema.xml; lineNumber: 1; 
columnNumber: 1; Final de archivo prematuro.  at 
org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1066)  at 
org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:256)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:418)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:399)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:518)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572) 
 at java.lang.Thread.run(Thread.java:745) Caused by: 
org.apache.solr.common.SolrException: Could not load conf for core collection1: 
Cant load schema 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_9C8587AC75677094-001/solr-instance-028/collection1/conf/schema.xml:
 org.xml.sax.SAXParseException; systemId: solrres:/schema.xml; lineNumber: 1; 
columnNumber: 1; Final de archivo prematuro.  at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:86)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:810)  at 
org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:466)  at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 ... 1 more Caused by: org.apache.solr.common.SolrException: Cant load 
schema 

[jira] [Commented] (LUCENE-7311) TermWeight shoud seek terms lazily

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7311:
-

I think this is too invasive of an optimization? Already the term-handling code 
in these queries (and this is by far the simplest one) is too much, I think 
"something has to give" to make the world a simpler place before we decide to 
do these kinds of optimizations? For example removal of 
querynorm/classicsimilarity could really start to simplify Weight.

> TermWeight shoud seek terms lazily
> --
>
> Key: LUCENE-7311
> URL: https://issues.apache.org/jira/browse/LUCENE-7311
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7311.patch
>
>
> Currently the terms are seeked eagerly in TermQuery.createWeight when 
> creating the TermContext. This might be wasteful when scores are not needed 
> since the query might be cached on some segments, thus seeking the term on 
> these segments is not needed. We could change TermWeight to only seek terms 
> in Weight.scorer when scores are not needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7311) TermWeight shoud seek terms lazily

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7311:
-
Attachment: LUCENE-7311.patch

Here is a patch.

> TermWeight shoud seek terms lazily
> --
>
> Key: LUCENE-7311
> URL: https://issues.apache.org/jira/browse/LUCENE-7311
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7311.patch
>
>
> Currently the terms are seeked eagerly in TermQuery.createWeight when 
> creating the TermContext. This might be wasteful when scores are not needed 
> since the query might be cached on some segments, thus seeking the term on 
> these segments is not needed. We could change TermWeight to only seek terms 
> in Weight.scorer when scores are not needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7311) TermWeight shoud seek terms lazily

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7311:


 Summary: TermWeight shoud seek terms lazily
 Key: LUCENE-7311
 URL: https://issues.apache.org/jira/browse/LUCENE-7311
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


Currently the terms are seeked eagerly in TermQuery.createWeight when creating 
the TermContext. This might be wasteful when scores are not needed since the 
query might be cached on some segments, thus seeking the term on these segments 
is not needed. We could change TermWeight to only seek terms in Weight.scorer 
when scores are not needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+120) - Build # 806 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/806/
Java: 32bit/jdk-9-ea+120 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure

Error Message:
Did not see a fully active cluster after 30 seconds

Stack Trace:
java.lang.AssertionError: Did not see a fully active cluster after 30 seconds
at 
__randomizedtesting.SeedInfo.seed([1F46059CFAF6AE50:9770A7CF22594642]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateWatcherIsRetainedOnPredicateFailure(TestCollectionStateWatchers.java:227)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




Build Log:
[...truncated 13198 lines...]
   

[jira] [Commented] (LUCENE-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7307:
--

Thanks Martijn, +1

> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE-7307, LUCENE_7307.patch, LUCENE_7307.patch, 
> LUCENE_7307.patch, LUCENE_7307.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen updated LUCENE-7307:
--
Attachment: LUCENE-7307

I've updated the patch.

> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE-7307, LUCENE_7307.patch, LUCENE_7307.patch, 
> LUCENE_7307.patch, LUCENE_7307.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9178) ExtractingRequestHandler doesn't strip HTML and adds metadata to content body

[Simon Blandford (JIRA)]

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

Simon Blandford updated SOLR-9178:
--
Affects Version/s: 5.0
  Description: 
Starting environment:
solr-6.0.1.tgz is downloaded and extracted. We are in the solr-6.0.1 directory.
The file, test.html, is downloaded from 
https://wiki.apache.org/solr/UsingMailingLists.

Affected versions: 4.10.3 is the last working version. 4.10.4 has some HTML 
comments and Javascript breaking through. Versions >5.0 have full symptoms 
described.

Steps to reproduce:
1) bin/solr start
2) bin/solr create -c mycore

3) curl 
"http://localhost:8983/solr/mycore/update/extract?literal.id=doc1=attr_=attr_content=true;
 -F "content/tutorial=@test.html"

4) curl http://localhost:8983/solr/mycore/select?q=information

Expected result: HTML->Text version of document indexed in  content 
body.

Actual result: Full HTML, but with anglebrackets removed, being indexed along 
with other unwanted metadata in the content body including fragments of CSS and 
Javascript that were in the source document. 

Head of response body below...



00informationdoc120440org.apache.tika.parser.DefaultParserorg.apache.tika.parser.html.HtmlParsertext/htmltest.htmlcontent/tutorialUsingMailingLists - Solr WikiUTF-8index,nofollowUsingMailingLists - Solr Wikitext/html; charset=utf-8 
 
 stylesheet text/css utf-8 all /wiki/modernized/css/common.css   stylesheet 
text/css utf-8 screen /wiki/modernized/css/screen.css   stylesheet text/css 
utf-8 print /wiki/modernized/css/print.css   stylesheet text/css utf-8 
projection /wiki/modernized/css/projection.css   alternate Solr Wiki: 
UsingMailingLists 
/solr/UsingMailingLists?diffs=1show_att=1action=rss_rcunique=0page=UsingMailingListsddiffs=1
 application/rss+xml   Start /solr/FrontPage   Alternate Wiki Markup 
/solr/UsingMailingLists?action=raw   Alternate print Print View 
/solr/UsingMailingLists?action=print   Search /solr/FindPage   Index 
/solr/TitleIndex   Glossary /solr/WordIndex   Help /solr/HelpOnFormatting   
stream_size 20440  
 X-Parsed-By org.apache.tika.parser.DefaultParser  
 X-Parsed-By org.apache.tika.parser.html.HtmlParser  
 stream_content_type text/html  
 stream_name test.html  
 stream_source_info content/tutorial  
 dc:title UsingMailingLists - Solr Wiki  
 Content-Encoding UTF-8  
 robots index,nofollow  
 Content-Type text/html; charset=utf-8  
 UsingMailingLists - Solr Wiki 
 
 

 header 

 application/x-www-form-urlencoded get searchform /solr/UsingMailingLists 
 
 hidden action fullsearch  
 hidden context 180  
 searchinput Search: 
 text searchinput value  20 searchFocus(this) searchBlur(this) 
searchChange(this) searchChange(this) Search  
 submit titlesearch titlesearch Titles Search Titles  
 submit fullsearch fullsearch Text Search Full Text  
 

 

 text/javascript 
!--// Initialize search form
var f = document.getElementById('searchform');
f.getElementsByTagName('label')[0].style.display = 'none';
var e = document.getElementById('searchinput');
searchChange(e);
searchBlur(e);
//--
 

 logo  rect /solr/FrontPage Solr Wiki  


  was:
Starting environment:
solr-6.0.1.tgz is downloaded and extracted. We are in the solr-6.0.1 directory.
The file, test.html, is downloaded from 
https://wiki.apache.org/solr/UsingMailingLists.

Steps to reproduce:
1) bin/solr start
2) bin/solr create -c mycore

3) curl 
"http://localhost:8983/solr/mycore/update/extract?literal.id=doc1=attr_=attr_content=true;
 -F "content/tutorial=@test.html"

4) curl http://localhost:8983/solr/mycore/select?q=information

Expected result: HTML->Text version of document indexed in  content 
body.

Actual result: Full HTML, but with anglebrackets removed, being indexed along 
with other unwanted metadata in the content body including fragments of CSS and 
Javascript that were in the source document. 

Head of response body below...



00informationdoc120440org.apache.tika.parser.DefaultParserorg.apache.tika.parser.html.HtmlParsertext/htmltest.htmlcontent/tutorialUsingMailingLists - Solr WikiUTF-8index,nofollowUsingMailingLists - Solr Wikitext/html; charset=utf-8 
 
 stylesheet text/css utf-8 all /wiki/modernized/css/common.css   stylesheet 
text/css utf-8 screen /wiki/modernized/css/screen.css   stylesheet text/css 
utf-8 print /wiki/modernized/css/print.css   stylesheet text/css utf-8 
projection /wiki/modernized/css/projection.css   alternate Solr Wiki: 
UsingMailingLists 
/solr/UsingMailingLists?diffs=1show_att=1action=rss_rcunique=0page=UsingMailingListsddiffs=1
 application/rss+xml   Start /solr/FrontPage   Alternate Wiki Markup 
/solr/UsingMailingLists?action=raw   Alternate print Print View 
/solr/UsingMailingLists?action=print   Search /solr/FindPage   Index 
/solr/TitleIndex   Glossary /solr/WordIndex   Help /solr/HelpOnFormatting   
stream_size 20440  
 X-Parsed-By org.apache.tika.parser.DefaultParser  
 X-Parsed-By 

[jira] [Commented] (LUCENE-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7307:
---

bq. I think the byte[] version was better since it is consitent with 
PointPangeQuery which exposes the low/high bounds as a byte[]?

Good point. I'll change that.

bq. Also I don't think it is true that the sortedPackedPoints iterator makes a 
copy: looking at PrefixCodedTerms, it seems to be reusing the same BytesRef 
object?

True... we need to make a copy. I guess what I was confused with is the copy 
that PrefixCodedTerms makes from the input, but if it is reusing the BytesRef 
it copies into then a copy is required if we return the points in a collection.

bq. Something else we should do is throwing a NoSuchElementException in the 
Iterator whin upTo==size to comply with the Iterator API.

+1!

> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE_7307.patch, LUCENE_7307.patch, LUCENE_7307.patch, 
> LUCENE_7307.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7304) Doc values based block join implementation

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7304:
---

bq. There is a dilemma here: either introduce DocBlocksIterator, or not 
implement MutableBits.

The block join queries are not using any of the methods that modify the bitset, 
so I think it is fine to not implement clear() and set() methods. Also it will 
not be a general purpose bitset, but specialized for the block join.

> Doc values based block join implementation
> --
>
> Key: LUCENE-7304
> URL: https://issues.apache.org/jira/browse/LUCENE-7304
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE-5092-20140313.patch, LUCENE-7304-20160531.patch, 
> LUCENE_7304.patch
>
>
> At query time the block join relies on a bitset for finding the previous 
> parent doc during advancing the doc id iterator. On large indices these 
> bitsets can consume large amounts of jvm heap space.  Also typically due the 
> nature how these bitsets are set, the 'FixedBitSet' implementation is used.
> The idea I had was to replace the bitset usage by a numeric doc values field 
> that stores offsets. Each child doc stores how many docids it is from its 
> parent doc and each parent stores how many docids it is apart from its first 
> child. At query time this information can be used to perform the block join.
> I think another benefit of this approach is that external tools can now 
> easily determine if a doc is part of a block of documents and perhaps this 
> also helps index time sorting?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+120) - Build # 16898 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16898/
Java: 64bit/jdk-9-ea+120 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([D0C25AD7E00EA301:6A1035AF63204D14]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:782)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:99)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529=standard=0=20=2.2
at 

[jira] [Commented] (LUCENE-7307) Add getters to PointInSetQuery and PointRangeQuery classes

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7307:
--

bq. Also I changed the return type from Collection to 
Collection because the sortedPackedPoints iterator already makes a 
copy and returns that as BytesRef.

I think the byte[] version was better since it is consitent with 
PointPangeQuery which exposes the low/high bounds as a byte[]? Also I don't 
think it is true that the sortedPackedPoints iterator makes a copy: looking at 
PrefixCodedTerms, it seems to be reusing the same BytesRef object?

Something else we should do is throwing a NoSuchElementException in the 
Iterator whin upTo==size to comply with the Iterator API.


> Add getters to PointInSetQuery and PointRangeQuery classes
> --
>
> Key: LUCENE-7307
> URL: https://issues.apache.org/jira/browse/LUCENE-7307
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Martijn van Groningen
>Priority: Trivial
> Attachments: LUCENE_7307.patch, LUCENE_7307.patch, LUCENE_7307.patch, 
> LUCENE_7307.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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