[JENKINS] Lucene-Solr-Tests-6.6 - Build # 45 - Still unstable

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.6/45/

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Something is broken in the assert for no shards using the same indexDir - 
probably something was changed in the attributes published in the MBean of 
SolrCore : {}

Stack Trace:
java.lang.AssertionError: Something is broken in the assert for no shards using 
the same indexDir - probably something was changed in the attributes published 
in the MBean of SolrCore : {}
at 
__randomizedtesting.SeedInfo.seed([CB4E4B01BDAA51DA:833B3FB5BB997E4F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.checkNoTwoShardsUseTheSameIndexDir(CollectionsAPIDistributedZkTest.java:646)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:524)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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-EA] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-10-ea+43) - Build # 2 - Still Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/2/
Java: 64bit/jdk-10-ea+43 -XX:-UseCompressedOops -XX:+UseG1GC

28 tests failed.
FAILED:  org.apache.solr.cloud.ZkControllerTest.testPublishAndWaitForDownStates

Error Message:
The ZkController.publishAndWaitForDownStates should have timed out but it didn't

Stack Trace:
java.lang.AssertionError: The ZkController.publishAndWaitForDownStates should 
have timed out but it didn't
at 
__randomizedtesting.SeedInfo.seed([ECC8222337F70D9A:CBC74ECF966042A5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.ZkControllerTest.testPublishAndWaitForDownStates(ZkControllerTest.java:306)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.cloud.ZkControllerTest.testPublishAndWaitForDownStates

Error Message:
The ZkController.publishAndWaitForDownStates should have timed out but it didn't

Stack Trace:

[jira] [Commented] (SOLR-11702) Redesign current LIR implementation

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11702:


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

SOLR-11702: Remove old LIR call in SolrCmdDistributor and let 
DistributedUpdateProcessor handle it on finish()


> Redesign current LIR implementation
> ---
>
> Key: SOLR-11702
> URL: https://issues.apache.org/jira/browse/SOLR-11702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11702.patch, SOLR-11702.patch
>
>
> I recently looked into some problem related to racing between LIR and 
> Recovering. I would like to propose a totally new approach to solve SOLR-5495 
> problem because fixing current implementation by a bandage will lead us to 
> other problems (we can not prove the correctness of the implementation).
> Feel free to give comments/thoughts about this new scheme.
> https://docs.google.com/document/d/1dM2GKMULsS45ZMuvtztVnM2m3fdUeRYNCyJorIIisEo/edit?usp=sharing



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

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



[jira] [Commented] (SOLR-11702) Redesign current LIR implementation

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11702:


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

SOLR-11702: Remove old LIR call in SolrCmdDistributor and let 
DistributedUpdateProcessor handle it on finish()


> Redesign current LIR implementation
> ---
>
> Key: SOLR-11702
> URL: https://issues.apache.org/jira/browse/SOLR-11702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11702.patch, SOLR-11702.patch
>
>
> I recently looked into some problem related to racing between LIR and 
> Recovering. I would like to propose a totally new approach to solve SOLR-5495 
> problem because fixing current implementation by a bandage will lead us to 
> other problems (we can not prove the correctness of the implementation).
> Feel free to give comments/thoughts about this new scheme.
> https://docs.google.com/document/d/1dM2GKMULsS45ZMuvtztVnM2m3fdUeRYNCyJorIIisEo/edit?usp=sharing



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

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



[jira] [Commented] (SOLR-12011) Consistence problem when in-sync replicas are DOWN

2018-03-01 Thread Cao Manh Dat (JIRA)

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

Cao Manh Dat commented on SOLR-12011:
-

{quote}So I traced the code and a live fetch on the leader works fine today but 
as a side-effect. We set the term equal to max for a recoverying replica (using 
ZkShardTerms.startRecovering() method) in ZkController.publish *before* we 
publish the replica state to the overseer queue. So if the leader (during prep 
recovery) sees replica state as recoverying then Zookeeper also guarantees that 
it will see the max term published before the recoverying state was published. 
I think we should make this behavior clear via a code comment.
{quote}
Yeah, I will add a comment for clarification 
{quote}bq. The changes in SolrCmdDistributor fix a different bug, no? Describe 
the problem here in this issue and how it is solved. Otherwise extract it to 
its own ticket.
{quote}
Hmm, you're right, maybe the changes in SolrCmdDistributor should go into 
SOLR-11702
{quote}Latest patch added changes for RestoreCoreOp and SplitOp where an empty 
core is added new data
{quote}
The destination for {{RestoreCoreOp}} and {{SplitOp}} should be for slice with 
no more than 1 replicas, and that how some collections API use these admins 
API. If not, how can other replicas in the same shard acknowledge the changes 
and put themselves to recovery? 

> Consistence problem when in-sync replicas are DOWN
> --
>
> Key: SOLR-12011
> URL: https://issues.apache.org/jira/browse/SOLR-12011
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12011.patch, SOLR-12011.patch, SOLR-12011.patch, 
> SOLR-12011.patch
>
>
> Currently, we will meet consistency problem when in-sync replicas are DOWN. 
> For example:
>  1. A collection with 1 shard with 1 leader and 2 replicas
>  2. Nodes contain 2 replicas go down
>  3. The leader receives an update A, success
>  4. The node contains the leader goes down
>  5. 2 replicas come back
>  6. One of them become leader --> But they shouldn't become leader since they 
> missed the update A
> A solution to this issue :
>  * The idea here is using term value of each replica (SOLR-11702) will be 
> enough to tell that a replica received the latest updates or not. Therefore 
> only replicas with the highest term can become the leader.
>  * There are a couple of things need to be done on this issue
>  ** When leader receives the first updates, its term should be changed from 0 
> -> 1, so further replicas added to the same shard won't be able to become 
> leader (their term = 0) until they finish recovery
>  ** For DOWN replicas, the leader should also need to check (in DUP.finish()) 
> that those replicas have term less than leader before return results to users
>  ** Just by looking at term value of replica, it is not enough to tell us 
> that replica is in-sync with leader or not. Because that replica might not 
> finish the recovery process. We need to introduce another flag (stored on 
> shard term node on ZK) to tell us that replica finished recovery or not. It 
> will look like this.
>  *** {"code_node1" : 1, "core_node2" : 0} — (when core_node2 start recovery) 
> --->
>  *** {"core_node1" : 1, "core_node2" : 1, "core_node2_recovering" : 1} — 
> (when core_node2 finish recovery) --->
>  *** {"core_node1" : 1, "core_node2" : 1}



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

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



[jira] [Commented] (SOLR-12011) Consistence problem when in-sync replicas are DOWN

2018-03-01 Thread Shalin Shekhar Mangar (JIRA)

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

Shalin Shekhar Mangar commented on SOLR-12011:
--

bq. Should we? Replica only sends PrepRecoveryOp to the leader after success 
updates its term. So I think a live-fetch on the leader's side will be enough.  
And I'm afraid that looping at that call can cause an endless loop. ( I'm not 
sure about this point )

So I traced the code and a live fetch on the leader works fine today but as a 
side-effect. We set the term equal to max for a recoverying replica (using 
ZkShardTerms.startRecovering() method) in ZkController.publish *before* we 
publish the replica state to the overseer queue. So if the leader (during prep 
recovery) sees replica state as recoverying then Zookeeper also guarantees that 
it will see the max term published before the recoverying state was published. 
I think we should make this behavior clear via a code comment.

The changes in SolrCmdDistributor fix a different bug, no? Describe the problem 
here in this issue and how it is solved. Otherwise extract it to its own ticket.

bq. Latest patch added changes for  RestoreCoreOp and SplitOp where an empty 
core is added new data

I don't understand this change. It seems to disallow restore or split if the 
slice has more than 1 replicas?

> Consistence problem when in-sync replicas are DOWN
> --
>
> Key: SOLR-12011
> URL: https://issues.apache.org/jira/browse/SOLR-12011
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12011.patch, SOLR-12011.patch, SOLR-12011.patch, 
> SOLR-12011.patch
>
>
> Currently, we will meet consistency problem when in-sync replicas are DOWN. 
> For example:
>  1. A collection with 1 shard with 1 leader and 2 replicas
>  2. Nodes contain 2 replicas go down
>  3. The leader receives an update A, success
>  4. The node contains the leader goes down
>  5. 2 replicas come back
>  6. One of them become leader --> But they shouldn't become leader since they 
> missed the update A
> A solution to this issue :
>  * The idea here is using term value of each replica (SOLR-11702) will be 
> enough to tell that a replica received the latest updates or not. Therefore 
> only replicas with the highest term can become the leader.
>  * There are a couple of things need to be done on this issue
>  ** When leader receives the first updates, its term should be changed from 0 
> -> 1, so further replicas added to the same shard won't be able to become 
> leader (their term = 0) until they finish recovery
>  ** For DOWN replicas, the leader should also need to check (in DUP.finish()) 
> that those replicas have term less than leader before return results to users
>  ** Just by looking at term value of replica, it is not enough to tell us 
> that replica is in-sync with leader or not. Because that replica might not 
> finish the recovery process. We need to introduce another flag (stored on 
> shard term node on ZK) to tell us that replica finished recovery or not. It 
> will look like this.
>  *** {"code_node1" : 1, "core_node2" : 0} — (when core_node2 start recovery) 
> --->
>  *** {"core_node1" : 1, "core_node2" : 1, "core_node2_recovering" : 1} — 
> (when core_node2 finish recovery) --->
>  *** {"core_node1" : 1, "core_node2" : 1}



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

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



[jira] [Assigned] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread Noble Paul (JIRA)

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

Noble Paul reassigned SOLR-12050:
-

Assignee: Noble Paul

> UTILIZENODE does not enforce policy rules
> -
>
> Key: SOLR-12050
> URL: https://issues.apache.org/jira/browse/SOLR-12050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12050.log.txt
>
>
> I've been poking around TestUtilizeNode and some of it's recent jenkins 
> failures -- AFAICT the {{UTILIZENODE}} is not behaving correctly per it's 
> current documentation...
> bq. It tries to fix any policy violations first and then it tries to move 
> some load off of the most loaded nodes according to the preferences
> ...based on my testing w/a slightly modified testcase that does additional 
> logging/asserts, it will frequently choose to move a "random" replica to 
> move, even when there are existing replicas that violate the policy.
> I will be commiting my current improvements to the test while citing this 
> issue, and marking the test \@AwaitsFix  Then i'll attach some logs/comments 
> showing what i mean.



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

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



[jira] [Commented] (SOLR-12031) Refactor Policy framework to let state changes to be applied to all nodes

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12031:


Commit 23aee00213a2c48bd578bcf01a5ed435b0bdc881 in lucene-solr's branch 
refs/heads/master from noble
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=23aee00 ]

SOLR-12031: Refactor Policy framework to make simulated changes affect more 
than a single node
SOLR-12050: UTILIZENODE does not enforce policy rules


> Refactor Policy framework to let state changes to be applied to all nodes
> -
>
> Key: SOLR-12031
> URL: https://issues.apache.org/jira/browse/SOLR-12031
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12031.patch
>
>
> The framework assumes that all variables will change the values in the same 
> node only. that doesn't have to be the case.
>  
> for instance  , when a replica for a given shard is a added to a node, it 
> actually increases the search rate in that node and decrease the search rate 
> on other nodes that host the same shard.
>  



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

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



[jira] [Commented] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12050:


Commit 23aee00213a2c48bd578bcf01a5ed435b0bdc881 in lucene-solr's branch 
refs/heads/master from noble
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=23aee00 ]

SOLR-12031: Refactor Policy framework to make simulated changes affect more 
than a single node
SOLR-12050: UTILIZENODE does not enforce policy rules


> UTILIZENODE does not enforce policy rules
> -
>
> Key: SOLR-12050
> URL: https://issues.apache.org/jira/browse/SOLR-12050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-12050.log.txt
>
>
> I've been poking around TestUtilizeNode and some of it's recent jenkins 
> failures -- AFAICT the {{UTILIZENODE}} is not behaving correctly per it's 
> current documentation...
> bq. It tries to fix any policy violations first and then it tries to move 
> some load off of the most loaded nodes according to the preferences
> ...based on my testing w/a slightly modified testcase that does additional 
> logging/asserts, it will frequently choose to move a "random" replica to 
> move, even when there are existing replicas that violate the policy.
> I will be commiting my current improvements to the test while citing this 
> issue, and marking the test \@AwaitsFix  Then i'll attach some logs/comments 
> showing what i mean.



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

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



[jira] [Commented] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12050:


Commit 888c6260f122d03beec03615469dbed444ab62e7 in lucene-solr's branch 
refs/heads/branch_7x from noble
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=888c626 ]

SOLR-12031: Refactor Policy framework to make simulated changes affect more 
than a single node
SOLR-12050: UTILIZENODE does not enforce policy rules


> UTILIZENODE does not enforce policy rules
> -
>
> Key: SOLR-12050
> URL: https://issues.apache.org/jira/browse/SOLR-12050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-12050.log.txt
>
>
> I've been poking around TestUtilizeNode and some of it's recent jenkins 
> failures -- AFAICT the {{UTILIZENODE}} is not behaving correctly per it's 
> current documentation...
> bq. It tries to fix any policy violations first and then it tries to move 
> some load off of the most loaded nodes according to the preferences
> ...based on my testing w/a slightly modified testcase that does additional 
> logging/asserts, it will frequently choose to move a "random" replica to 
> move, even when there are existing replicas that violate the policy.
> I will be commiting my current improvements to the test while citing this 
> issue, and marking the test \@AwaitsFix  Then i'll attach some logs/comments 
> showing what i mean.



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

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



[jira] [Commented] (SOLR-12031) Refactor Policy framework to let state changes to be applied to all nodes

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12031:


Commit 888c6260f122d03beec03615469dbed444ab62e7 in lucene-solr's branch 
refs/heads/branch_7x from noble
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=888c626 ]

SOLR-12031: Refactor Policy framework to make simulated changes affect more 
than a single node
SOLR-12050: UTILIZENODE does not enforce policy rules


> Refactor Policy framework to let state changes to be applied to all nodes
> -
>
> Key: SOLR-12031
> URL: https://issues.apache.org/jira/browse/SOLR-12031
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12031.patch
>
>
> The framework assumes that all variables will change the values in the same 
> node only. that doesn't have to be the case.
>  
> for instance  , when a replica for a given shard is a added to a node, it 
> actually increases the search rate in that node and decrease the search rate 
> on other nodes that host the same shard.
>  



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

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



[JENKINS-EA] Lucene-Solr-BadApples-master-Linux (64bit/jdk-10-ea+43) - Build # 2 - Still Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/2/
Java: 64bit/jdk-10-ea+43 -XX:-UseCompressedOops -XX:+UseSerialGC

29 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.ltr.TestLTRReRankingPipeline

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.ltr.TestLTRReRankingPipeline: 1) Thread[id=17, 
name=LuceneTestCase-1-thread-2, state=WAITING, 
group=TGRP-TestLTRReRankingPipeline] at 
java.base@10/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@10/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2075)
 at 
java.base@10/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@10/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=16, name=LuceneTestCase-1-thread-1, state=WAITING, 
group=TGRP-TestLTRReRankingPipeline] at 
java.base@10/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@10/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2075)
 at 
java.base@10/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@10/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.ltr.TestLTRReRankingPipeline: 
   1) Thread[id=17, name=LuceneTestCase-1-thread-2, state=WAITING, 
group=TGRP-TestLTRReRankingPipeline]
at java.base@10/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@10/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@10/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2075)
at 
java.base@10/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
at 
java.base@10/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@10/java.lang.Thread.run(Thread.java:844)
   2) Thread[id=16, name=LuceneTestCase-1-thread-1, state=WAITING, 
group=TGRP-TestLTRReRankingPipeline]
at java.base@10/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@10/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@10/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2075)
at 
java.base@10/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
at 
java.base@10/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@10/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([4B438F654764A86A]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.ltr.TestLTRReRankingPipeline

Error Message:
There are still zombie threads that couldn't be terminated:1) Thread[id=17, 
name=LuceneTestCase-1-thread-2, state=WAITING, 
group=TGRP-TestLTRReRankingPipeline] at 
java.base@10/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@10/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2075)
 at 
java.base@10/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
 at 
java.base@10/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
 at 

[JENKINS] Lucene-Solr-NightlyTests-6.6 - Build # 32 - Still Unstable

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.6/32/

3 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([34BB004ACFA3C0F3:BF9CD39B8EA56B77]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1707/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testMetadata

Error Message:
Error from server at http://127.0.0.1:42348/solr: Collection : collection2meta 
is part of alias meta3 remove or modify the alias before removing this 
collection.

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:42348/solr: Collection : collection2meta is 
part of alias meta3 remove or modify the alias before removing this collection.
at 
__randomizedtesting.SeedInfo.seed([B7B563BE2D2C5BDF:BEA529BA6AC507B6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:444)
at 
org.apache.solr.cloud.AliasIntegrationTest.tearDown(AliasIntegrationTest.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
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-7.x - Build # 163 - Unstable

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/163/

1 tests failed.
FAILED:  org.apache.lucene.analysis.core.TestRandomChains.testRandomChains

Error Message:
startOffset must be non-negative, and endOffset must be >= startOffset, and 
offsets must not go backwards startOffset=0,endOffset=2,lastStartOffset=2 for 
field 'dummy'

Stack Trace:
java.lang.IllegalArgumentException: startOffset must be non-negative, and 
endOffset must be >= startOffset, and offsets must not go backwards 
startOffset=0,endOffset=2,lastStartOffset=2 for field 'dummy'
at 
__randomizedtesting.SeedInfo.seed([42AB66D0EBBF876:39CB9F0C49A9E5B6]:0)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:767)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:430)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:392)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:240)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:497)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1729)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1464)
at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:171)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:672)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:562)
at 
org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:856)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+43) - Build # 1456 - Still Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1456/
Java: 64bit/jdk-10-ea+43 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit

Error Message:
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([C580C5964A2A5011:3CCD5639765F1D9B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:283)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Commented] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11993:


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

SOLR-11993: LeaderInitiatedRecoveryThread does not retry on UnknownHostException


> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 6.6.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[jira] [Assigned] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe reassigned SOLR-11993:
-

Assignee: Steve Rowe

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Assignee: Steve Rowe
>Priority: Major
> Fix For: 6.6.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[jira] [Resolved] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe resolved SOLR-11993.
---
Resolution: Fixed

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Assignee: Steve Rowe
>Priority: Major
> Fix For: 6.6.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[jira] [Comment Edited] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Koji Sekiguchi (JIRA)

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

Koji Sekiguchi edited comment on SOLR-11795 at 3/2/18 3:02 AM:
---

Hi Uwe,

I created the following branches:

* SOLR-11795 (for master)
* branch_7x-SOLR-11795 (for branch_7x)

Sorry to put you to the trouble but can you setup the Linux and Windows 
Policeman Jenkins jobs that you kindly suggested a week ago? Thank you very 
much in advance!


was (Author: koji):
Hi Uwe,

I created the following branches:

* SOLR-1175 (for master)
* branch_7x-SOLR-1175 (for branch_7x)

Sorry to put you to the trouble but can you setup the Linux and Windows 
Policeman Jenkins jobs that you kindly suggested a week ago? Thank you very 
much in advance!

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Koji Sekiguchi (JIRA)

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

Koji Sekiguchi commented on SOLR-11795:
---

Hi Uwe,

I created the following branches:

* SOLR-1175 (for master)
* branch_7x-SOLR-1175 (for branch_7x)

Sorry to put you to the trouble but can you setup the Linux and Windows 
Policeman Jenkins jobs that you kindly suggested a week ago? Thank you very 
much in advance!

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[jira] [Assigned] (SOLR-11885) Solrj client deleteByIds handle route request miss wrap basic auth credentials

2018-03-01 Thread Erick Erickson (JIRA)

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

Erick Erickson reassigned SOLR-11885:
-

Assignee: Erick Erickson

> Solrj client deleteByIds handle route request miss wrap basic auth credentials
> --
>
> Key: SOLR-11885
> URL: https://issues.apache.org/jira/browse/SOLR-11885
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 5.5.5, 6.6.2, 7.2.1
>Reporter: Aibao Luo
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 6.6.3
>
> Attachments: SOLR-11885.patch
>
>
>  
> {code:java}
> public Map getRoutes(DocRouter router, 
> DocCollection col, Map urlMap, ModifiableSolrParams 
> params, String idField) { 
>   
>   if (request != null) {  
> UpdateRequest urequest = (UpdateRequest) request.getRequest();
>    urequest.deleteById(deleteId, version);
>   } else{  
> UpdateRequest urequest = new UpdateRequest(); 
>    urequest.setParams(params); 
>    urequest.deleteById(deleteId, version); 
>    urequest.setCommitWithin(getCommitWithin()); 
>    request = new LBHttpSolrClient.Req(urequest, urls); 
>    routes.put(leaderUrl, request);
>  } 
>  
> }  
> {code}
>  
> while delete by ids, inner wrapped request to routed slice should contains  
> auth credentials from source request, as adding documents does.



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

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



[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11795:


Commit 961269aa5d0feef86cac9b4a94c2268de9f498f6 in lucene-solr's branch 
refs/heads/branch_7x-SOLR-11795 from koji
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=961269a ]

SOLR-11795: Add Solr metrics exporter for Prometheus


> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-11503:
---

On the branch_6_6 backport I fixed a missing import in CoreContainer.java.

There is a reproducing failure a local test run turned up:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=LegacyCloudClusterPropTest 
-Dtests.method=testCreateCollectionSwitchLegacyCloud 
-Dtests.seed=3E3D3F067ED986BE -Dtests.slow=true -Dtests.locale=zh-SG 
-Dtests.timezone=America/Rio_Branco -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 3.60s | 
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Should have found 
property replicaType in properties file
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([3E3D3F067ED986BE:EF3ACD83DAD60D8C]:0)
   [junit4]>at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.checkMandatoryProps(LegacyCloudClusterPropTest.java:158)
   [junit4]>at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:90)
   [junit4]>at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:69)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}

[~erickerickson], does this ring a bell?

> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, 
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until 

[jira] [Commented] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-11993:
---

Thanks [~caomanhdat]!  Committing shortly.

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 6.6.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11503:


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

SOLR-11503: add missing import


> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, 
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



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

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



[JENKINS] Lucene-Solr-6.6-Linux (64bit/jdk-9.0.4) - Build # 180 - Failure!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/180/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 1724 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/core/test/temp/junit4-J1-20180302_020859_4022008001082862958723.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] WARNING: An illegal reflective access operation has occurred
   [junit4] WARNING: Illegal reflective access by 
org.apache.lucene.util.RamUsageTester 
(file:/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/test-framework/classes/java/)
 to field java.util.ArrayList.elementData
   [junit4] WARNING: Please consider reporting this to the maintainers of 
org.apache.lucene.util.RamUsageTester
   [junit4] WARNING: Use --illegal-access=warn to enable warnings of further 
illegal reflective access operations
   [junit4] WARNING: All illegal access operations will be denied in a future 
release
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/core/test/temp/junit4-J2-20180302_020859_40616373091173624851026.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] WARNING: An illegal reflective access operation has occurred
   [junit4] WARNING: Illegal reflective access by 
org.apache.lucene.util.RamUsageTester 
(file:/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/test-framework/classes/java/)
 to field java.lang.String.value
   [junit4] WARNING: Please consider reporting this to the maintainers of 
org.apache.lucene.util.RamUsageTester
   [junit4] WARNING: Use --illegal-access=warn to enable warnings of further 
illegal reflective access operations
   [junit4] WARNING: All illegal access operations will be denied in a future 
release
   [junit4] <<< JVM J2: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/core/test/temp/junit4-J0-20180302_020859_4065043799109137855982.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] WARNING: An illegal reflective access operation has occurred
   [junit4] WARNING: Illegal reflective access by 
org.apache.lucene.util.RamUsageTester 
(file:/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/test-framework/classes/java/)
 to field java.util.ArrayList.elementData
   [junit4] WARNING: Please consider reporting this to the maintainers of 
org.apache.lucene.util.RamUsageTester
   [junit4] WARNING: Use --illegal-access=warn to enable warnings of further 
illegal reflective access operations
   [junit4] WARNING: All illegal access operations will be denied in a future 
release
   [junit4] <<< JVM J0: EOF 

[...truncated 291 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/test-framework/test/temp/junit4-J1-20180302_021453_3237234531391516948897.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] WARNING: An illegal reflective access operation has occurred
   [junit4] WARNING: Illegal reflective access by 
org.apache.lucene.util.RamUsageTester 
(file:/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/test-framework/classes/java/)
 to field java.util.Collections$SynchronizedCollection.c
   [junit4] WARNING: Please consider reporting this to the maintainers of 
org.apache.lucene.util.RamUsageTester
   [junit4] WARNING: Use --illegal-access=warn to enable warnings of further 
illegal reflective access operations
   [junit4] WARNING: All illegal access operations will be denied in a future 
release
   [junit4] <<< JVM J1: EOF 

[...truncated 6 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/test-framework/test/temp/junit4-J0-20180302_021453_32111023576971306793173.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] WARNING: An illegal reflective access operation has occurred
   [junit4] WARNING: Illegal reflective access by 
org.apache.lucene.util.RamUsageTester 
(file:/home/jenkins/workspace/Lucene-Solr-6.6-Linux/lucene/build/test-framework/classes/java/)
 to field java.util.Collections$SynchronizedCollection.c
   [junit4] WARNING: Please consider reporting this to the maintainers of 
org.apache.lucene.util.RamUsageTester
   [junit4] WARNING: Use --illegal-access=warn to enable warnings of further 
illegal reflective access operations
   [junit4] WARNING: All illegal access operations will be denied in a future 
release
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11795:


Commit 328800efc939a52c94f7b92c2d4cc4de2066215b in lucene-solr's branch 
refs/heads/SOLR-11795 from koji
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=328800e ]

SOLR-11795: Add Solr metrics exporter for Prometheus


> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[jira] [Updated] (SOLR-12047) Solr 7.x restart can fail to load some cores

2018-03-01 Thread Cao Manh Dat (JIRA)

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

Cao Manh Dat updated SOLR-12047:

Attachment: SOLR-12047.patch

> Solr 7.x restart can fail to load some cores
> 
>
> Key: SOLR-12047
> URL: https://issues.apache.org/jira/browse/SOLR-12047
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Varun Thacker
>Priority: Major
> Attachments: SOLR-12047.patch
>
>
> I've seen this with 2 users running Solr 7.2.1 in the last 2 days where a 
> restart fails to load some cores on a node. 
>  
> Here's the stack trace
>  
>  
> {noformat}
> date time ERROR 
> (coreLoadExecutor-6-thread-2-processing-n:solr-number:8983_solr) [c:name 
> s:shard r:core_node130 x:collection_shard_replica] o.a.s.c.ZkController 
> org.apache.solr.common.SolrException: coreNodeName core_node130 does not 
> exist in shard shard4: 
> DocCollection(collection_name//collections/collection_name/state.json/2385)={
> ..collection state.json ...
> }
> at org.apache.solr.cloud.ZkController.checkStateInZk(ZkController.java:1687)
> at org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1590)
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1030)
> ...
> at java.lang.Thread.run(Thread.java:748)
> date time ERROR 
> (coreContainerWorkExecutor-2-thread-1-processing-n:solr-number:8983_solr) [ ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core 
> [collection_shardX_replica_n129]
> ...
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.solr.common.SolrException: Unable to create core 
> [collection_shardX_replica_n129]
> ...
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: 
> at org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1619)
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1030)
> ... 7 more{noformat}
> I created the Jira saying Solr 7.x since it's tied to legacyCloud being set 
> to false by default starting Solr 7.0
>  
>  
> In ZkController#checkStateInZk where the block is only run with 
> legacyCloud=false ( L1645 ) we do a waitForState ( L1667 ) and only wait 3 
> seconds. If we don't get the desired state the core will fail to load 
>  
> With big enough clusters this 3 second timeout is too low and we should 
> increase it to a large number such that we don't cause core initialization 
> failures 
> Line reference is from Solr 7.2.1



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

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



[jira] [Commented] (SOLR-12047) Solr 7.x restart can fail to load some cores

2018-03-01 Thread Cao Manh Dat (JIRA)

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

Cao Manh Dat commented on SOLR-12047:
-

Patch for this ticket, I think it can be committed soon.

> Solr 7.x restart can fail to load some cores
> 
>
> Key: SOLR-12047
> URL: https://issues.apache.org/jira/browse/SOLR-12047
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Varun Thacker
>Priority: Major
> Attachments: SOLR-12047.patch
>
>
> I've seen this with 2 users running Solr 7.2.1 in the last 2 days where a 
> restart fails to load some cores on a node. 
>  
> Here's the stack trace
>  
>  
> {noformat}
> date time ERROR 
> (coreLoadExecutor-6-thread-2-processing-n:solr-number:8983_solr) [c:name 
> s:shard r:core_node130 x:collection_shard_replica] o.a.s.c.ZkController 
> org.apache.solr.common.SolrException: coreNodeName core_node130 does not 
> exist in shard shard4: 
> DocCollection(collection_name//collections/collection_name/state.json/2385)={
> ..collection state.json ...
> }
> at org.apache.solr.cloud.ZkController.checkStateInZk(ZkController.java:1687)
> at org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1590)
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1030)
> ...
> at java.lang.Thread.run(Thread.java:748)
> date time ERROR 
> (coreContainerWorkExecutor-2-thread-1-processing-n:solr-number:8983_solr) [ ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core 
> [collection_shardX_replica_n129]
> ...
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.solr.common.SolrException: Unable to create core 
> [collection_shardX_replica_n129]
> ...
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: 
> at org.apache.solr.cloud.ZkController.preRegister(ZkController.java:1619)
> at 
> org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1030)
> ... 7 more{noformat}
> I created the Jira saying Solr 7.x since it's tied to legacyCloud being set 
> to false by default starting Solr 7.0
>  
>  
> In ZkController#checkStateInZk where the block is only run with 
> legacyCloud=false ( L1645 ) we do a waitForState ( L1667 ) and only wait 3 
> seconds. If we don't get the desired state the core will fail to load 
>  
> With big enough clusters this 3 second timeout is too low and we should 
> increase it to a large number such that we don't cause core initialization 
> failures 
> Line reference is from Solr 7.2.1



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

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



[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Shinichiro Abe (JIRA)

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

Shinichiro Abe commented on SOLR-11795:
---

i made a mistake when looking the patch, please ignore that, sorry.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[jira] [Commented] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Cao Manh Dat (JIRA)

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

Cao Manh Dat commented on SOLR-11993:
-

+1 [~steve_rowe] It looks good to me

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 6.6.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



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

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-repro/173/

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

[repro] Revision: 2289c27c947f6f6a7cc96ae1839ba53e5ccc3fc1

[repro] Repro line:  ant test  -Dtestcase=TestJmxIntegration 
-Dtests.method=testJmxOnCoreReload -Dtests.seed=E1D4D541C688ADB6 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=vi-VN -Dtests.timezone=Indian/Chagos -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ZkControllerTest 
-Dtests.method=testPublishAndWaitForDownStates -Dtests.seed=E1D4D541C688ADB6 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=cs 
-Dtests.timezone=America/Puerto_Rico -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=E1D4D541C688ADB6 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=es-AR -Dtests.timezone=America/Bogota -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestLTRReRankingPipeline 
-Dtests.method=testDifferentTopN -Dtests.seed=ADF49C77C6243E25 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=es-CU -Dtests.timezone=Asia/Pyongyang -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
acf87b318eb2641b8869b43420e10e91a9aab797
[repro] git fetch
[repro] git checkout 2289c27c947f6f6a7cc96ae1839ba53e5ccc3fc1

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   TestReplicationHandler
[repro]   TestJmxIntegration
[repro]   ZkControllerTest
[repro] ant compile-test

[...truncated 2563 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=ADF49C77C6243E25 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=es-CU -Dtests.timezone=Asia/Pyongyang 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

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

[repro] ant compile-test

[...truncated 1329 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestReplicationHandler|*.TestJmxIntegration|*.ZkControllerTest"
 -Dtests.showOutput=onerror  -Dtests.seed=E1D4D541C688ADB6 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-AR 
-Dtests.timezone=America/Bogota -Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline

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

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro]solr/core
[repro]   TestReplicationHandler
[repro]   TestJmxIntegration
[repro]   ZkControllerTest
[repro] ant compile-test

[...truncated 2563 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=ADF49C77C6243E25 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=es-CU -Dtests.timezone=Asia/Pyongyang 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

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

[repro] ant compile-test

[...truncated 1329 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.TestReplicationHandler|*.TestJmxIntegration|*.ZkControllerTest"
 -Dtests.showOutput=onerror  -Dtests.seed=E1D4D541C688ADB6 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-AR 
-Dtests.timezone=America/Bogota -Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] Failures at the tip of master:
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline

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

[...truncated 8 lines...]
[repro] Test 

[jira] [Commented] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread Hoss Man (JIRA)

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

Hoss Man commented on SOLR-12050:
-


I've attached a sample log file from running this test after my assert/logging 
updates, if you look for the new logging messages, it's pretty easy to see that 
while the 2nd UTILIZE command is causing a replica to be moved onto the new 
node (jettyY), it seems to be completley ignoring the fact that there is a core 
hosted on a "blacklist" (per the policy) port (jettyX) that should be the first 
candidate for being moved...

{noformat}
  // in this particular run, the first UTILIZENODE command works,
  // it moves a replica off a random node to jettyX/3
  //
  // (allthough see TODO in test -- based on how the docs are worded,
  // it's not clear if there's any requirement that it do so)
  
9201 INFO  (TEST-TestUtilizeNode.test-seed#[78A4DE08FC5237FE]) [] 
o.a.s.c.TestUtilizeNode Sending UTILIZE command for jettyX 
(127.0.0.1:3_solr)
9204 INFO  (qtp1498399719-45) [n:127.0.0.1:33567_solr] 
o.a.s.h.a.CollectionsHandler Invoked Collection Action :utilizenode with params 
node=127.0.0.1:3_solr=UTILIZENODE=javabin=2 and 
sendToOCPQueue=true
  ...
9355 INFO  
(OverseerThreadFactory-20-thread-3-processing-n:127.0.0.1:46180_solr) 
[n:127.0.0.1:46180_solr] o.a.s.c.a.c.MoveReplicaCmd Replica will be moved 
to node 127.0.0.1:3_solr: 
core_node8:{"core":"utilizenodecoll_shard2_replica_n7","base_url":"http://127.0.0.1:33567/solr","node_name":"127.0.0.1:33567_solr","state":"active","type":"NRT"}
9361 INFO  
(OverseerThreadFactory-20-thread-3-processing-n:127.0.0.1:46180_solr) 
[n:127.0.0.1:46180_solr] o.a.s.c.a.c.AddReplicaCmd Node Identified 
127.0.0.1:3_solr for creating new replica
  ...
10078 INFO  (qtp1498399719-45) [n:127.0.0.1:33567_solr] 
o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/collections 
params={node=127.0.0.1:3_solr=UTILIZENODE=javabin=2} 
status=0 QTime=874
  
  // next up, sanity check which replicas jettyX/3 now has,
  // then set a new policy saying that port 3 should have 0 replicas...

10079 INFO  (TEST-TestUtilizeNode.test-seed#[78A4DE08FC5237FE]) [] 
o.a.s.c.TestUtilizeNode jettyX replicas prior to being blacklisted: 
[core_node10:{"core":"utilizenodecoll_shard2_replica_n9","base_url":"http://127.0.0.1:3/solr","node_name":"127.0.0.1:3_solr","state":"recovering","type":"NRT"}]
10079 INFO  (TEST-TestUtilizeNode.test-seed#[78A4DE08FC5237FE]) [] 
o.a.s.c.TestUtilizeNode Setting new policy to blacklist jettyX 
(127.0.0.1:3_solr) port=3
  ...
10143 INFO  (qtp1498399719-27) [n:127.0.0.1:33567_solr] 
o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/autoscaling 
params={wt=javabin=2} status=0 QTime=59

  // now spin up another new node: jettyY/55619, 
  // redundently sanity check the replicas on jettyX again,

10144 INFO  (TEST-TestUtilizeNode.test-seed#[78A4DE08FC5237FE]) [] 
o.a.s.c.TestUtilizeNode Spinning up additional jettyY...
  ...
10361 INFO  (zkConnectionManagerCallback-78-thread-1) [] 
o.a.s.c.c.ConnectionManager zkClient has connected
10365 INFO  (TEST-TestUtilizeNode.test-seed#[78A4DE08FC5237FE]) [] 
o.a.s.c.TestUtilizeNode jettyX replicas prior to utilizing jettyY: 
[core_node10:{"core":"utilizenodecoll_shard2_replica_n9","base_url":"http://127.0.0.1:3/solr","node_name":"127.0.0.1:3_solr","state":"recovering","type":"NRT"}]

  // Now send a UTILIZENODE command for jettyY/55619,
  // this *should* move the replica from jettyX->jettyY
  // (in order to resolve the existing policy violation)

10365 INFO  (TEST-TestUtilizeNode.test-seed#[78A4DE08FC5237FE]) [] 
o.a.s.c.TestUtilizeNode Sending UTILIZE command for jettyY 
(127.0.0.1:55619_solr)
10366 INFO  (qtp1498399719-45) [n:127.0.0.1:33567_solr] 
o.a.s.h.a.CollectionsHandler Invoked Collection Action :utilizenode with params 
node=127.0.0.1:55619_solr=UTILIZENODE=javabin=2 and 
sendToOCPQueue=true
  ...
10448 INFO  
(OverseerThreadFactory-20-thread-4-processing-n:127.0.0.1:46180_solr) 
[n:127.0.0.1:46180_solr] o.a.s.c.a.c.MoveReplicaCmd Replica will be moved 
to node 127.0.0.1:55619_solr: 
core_node6:{"core":"utilizenodecoll_shard2_replica_n5","base_url":"http://127.0.0.1:46180/solr","node_name":"127.0.0.1:46180_solr","state":"active","type":"NRT","leader":"true"}
10450 INFO  
(OverseerThreadFactory-20-thread-4-processing-n:127.0.0.1:46180_solr) 
[n:127.0.0.1:46180_solr] o.a.s.c.a.c.AddReplicaCmd Node Identified 
127.0.0.1:55619_solr for creating new replica
  ...
12710 INFO  (qtp1498399719-45) [n:127.0.0.1:33567_solr] 
o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/collections 
params={node=127.0.0.1:55619_solr=UTILIZENODE=javabin=2} 
status=0 QTime=2343

  // but as you can see above, the replica that's added to jettyY/55619
  // comes from a completley different node on port 

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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1455/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit

Error Message:
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([71909E92264CD1DA:88DD0D3D1A399C50]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:283)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Updated] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread Hoss Man (JIRA)

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

Hoss Man updated SOLR-12050:

Attachment: SOLR-12050.log.txt

> UTILIZENODE does not enforce policy rules
> -
>
> Key: SOLR-12050
> URL: https://issues.apache.org/jira/browse/SOLR-12050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
> Attachments: SOLR-12050.log.txt
>
>
> I've been poking around TestUtilizeNode and some of it's recent jenkins 
> failures -- AFAICT the {{UTILIZENODE}} is not behaving correctly per it's 
> current documentation...
> bq. It tries to fix any policy violations first and then it tries to move 
> some load off of the most loaded nodes according to the preferences
> ...based on my testing w/a slightly modified testcase that does additional 
> logging/asserts, it will frequently choose to move a "random" replica to 
> move, even when there are existing replicas that violate the policy.
> I will be commiting my current improvements to the test while citing this 
> issue, and marking the test \@AwaitsFix  Then i'll attach some logs/comments 
> showing what i mean.



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

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



[jira] [Commented] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12050:


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

SOLR-12050: mark TestUtilizeNode as AwaitsFix as well as adding additional 
logging/assertions to help see what the bug is

(cherry picked from commit 0424d9c06ba52037024ce5f0f678b2aca8c34fb7)


> UTILIZENODE does not enforce policy rules
> -
>
> Key: SOLR-12050
> URL: https://issues.apache.org/jira/browse/SOLR-12050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> I've been poking around TestUtilizeNode and some of it's recent jenkins 
> failures -- AFAICT the {{UTILIZENODE}} is not behaving correctly per it's 
> current documentation...
> bq. It tries to fix any policy violations first and then it tries to move 
> some load off of the most loaded nodes according to the preferences
> ...based on my testing w/a slightly modified testcase that does additional 
> logging/asserts, it will frequently choose to move a "random" replica to 
> move, even when there are existing replicas that violate the policy.
> I will be commiting my current improvements to the test while citing this 
> issue, and marking the test \@AwaitsFix  Then i'll attach some logs/comments 
> showing what i mean.



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

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



[jira] [Commented] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12050:


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

SOLR-12050: mark TestUtilizeNode as AwaitsFix as well as adding additional 
logging/assertions to help see what the bug is


> UTILIZENODE does not enforce policy rules
> -
>
> Key: SOLR-12050
> URL: https://issues.apache.org/jira/browse/SOLR-12050
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> I've been poking around TestUtilizeNode and some of it's recent jenkins 
> failures -- AFAICT the {{UTILIZENODE}} is not behaving correctly per it's 
> current documentation...
> bq. It tries to fix any policy violations first and then it tries to move 
> some load off of the most loaded nodes according to the preferences
> ...based on my testing w/a slightly modified testcase that does additional 
> logging/asserts, it will frequently choose to move a "random" replica to 
> move, even when there are existing replicas that violate the policy.
> I will be commiting my current improvements to the test while citing this 
> issue, and marking the test \@AwaitsFix  Then i'll attach some logs/comments 
> showing what i mean.



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

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



[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Minoru Osuka (JIRA)

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

Minoru Osuka commented on SOLR-11795:
-

[~shinichiro abe],

Thank you for finding a typo.
Argparse4j dependency? Could you please show me the code of the question in 
this patch so that I can understand your question?

[~koji] and [~thetaphi],

I Attach a patch (SOLR-11795-11.patch) that fixed typo.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[JENKINS] Solr-Artifacts-6.6 - Build # 34 - Failure

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Solr-Artifacts-6.6/34/

No tests ran.

Build Log:
[...truncated 14 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:862)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress git://git.apache.org/lucene-solr.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: remote: Counting objects: 31856, done.
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1715)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:405)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:207)
at hudson.remoting.UserRequest.perform(UserRequest.java:53)
at hudson.remoting.Request$2.run(Request.java:358)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
lucene
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
at hudson.remoting.Channel.call(Channel.java:908)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1042.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy111.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:860)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
ERROR: Error fetching remote repo 'origin'
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git 

[jira] [Updated] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Minoru Osuka (JIRA)

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

Minoru Osuka updated SOLR-11795:

Attachment: SOLR-11795-11.patch

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



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

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2396/

1 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
https://127.0.0.1:44130/solr/awhollynewcollection_0_shard1_replica_n1: 
ClusterState says we are the leader 
(https://127.0.0.1:44130/solr/awhollynewcollection_0_shard1_replica_n1), but 
locally we don't think so. Request came from null

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at 
https://127.0.0.1:44130/solr/awhollynewcollection_0_shard1_replica_n1: 
ClusterState says we are the leader 
(https://127.0.0.1:44130/solr/awhollynewcollection_0_shard1_replica_n1), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([4A630D701ADFC98C:21679C41CECE619]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:463)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/483/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestBackwardsCompatibility

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.4.1-cfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.4.1-cfs-001

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.1.0-cfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.1.0-cfs-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.4.1-cfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.4.1-cfs-001
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.1.0-cfs-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\backward-codecs\test\J0\temp\lucene.index.TestBackwardsCompatibility_564ADFADD377B8C0-001\2.1.0-cfs-001

at __randomizedtesting.SeedInfo.seed([564ADFADD377B8C0]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.DistributedIntervalFacetingTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.DistributedIntervalFacetingTest_246F5F6BFAC1AB2B-001\tempDir-001\shard1\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.DistributedIntervalFacetingTest_246F5F6BFAC1AB2B-001\tempDir-001\shard1\collection1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.DistributedIntervalFacetingTest_246F5F6BFAC1AB2B-001\tempDir-001\shard1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.DistributedIntervalFacetingTest_246F5F6BFAC1AB2B-001\tempDir-001\shard1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.DistributedIntervalFacetingTest_246F5F6BFAC1AB2B-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.DistributedIntervalFacetingTest_246F5F6BFAC1AB2B-001\tempDir-001
 

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

[jira] [Created] (SOLR-12050) UTILIZENODE does not enforce policy rules

2018-03-01 Thread Hoss Man (JIRA)
Hoss Man created SOLR-12050:
---

 Summary: UTILIZENODE does not enforce policy rules
 Key: SOLR-12050
 URL: https://issues.apache.org/jira/browse/SOLR-12050
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


I've been poking around TestUtilizeNode and some of it's recent jenkins 
failures -- AFAICT the {{UTILIZENODE}} is not behaving correctly per it's 
current documentation...

bq. It tries to fix any policy violations first and then it tries to move some 
load off of the most loaded nodes according to the preferences

...based on my testing w/a slightly modified testcase that does additional 
logging/asserts, it will frequently choose to move a "random" replica to move, 
even when there are existing replicas that violate the policy.

I will be commiting my current improvements to the test while citing this 
issue, and marking the test \@AwaitsFix  Then i'll attach some logs/comments 
showing what i mean.



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

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



[jira] [Commented] (LUCENE-8182) BoostingQuery applies the wrong boost to the query score

2018-03-01 Thread Jim Ferenczi (JIRA)

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

Jim Ferenczi commented on LUCENE-8182:
--

Thanks [~hossman] . I pushed a commit to add the missing changes in master. 

> BoostingQuery applies the wrong boost to the query score
> 
>
> Key: LUCENE-8182
> URL: https://issues.apache.org/jira/browse/LUCENE-8182
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Jim Ferenczi
>Priority: Major
> Fix For: 7.3
>
> Attachments: LUCENE-8182.patch, LUCENE-8182.patch, LUCENE-8182.patch
>
>
> BoostingQuery applies the parent query boost instead of the boost set on the 
> query due to a name clash in the anonymous class created by the createWeight 
> method.



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

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



[jira] [Commented] (LUCENE-8182) BoostingQuery applies the wrong boost to the query score

2018-03-01 Thread ASF subversion and git services (JIRA)

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

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

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

LUCENE-8182: update changes.txt with missing bug fix in 7.3.0


> BoostingQuery applies the wrong boost to the query score
> 
>
> Key: LUCENE-8182
> URL: https://issues.apache.org/jira/browse/LUCENE-8182
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Jim Ferenczi
>Priority: Major
> Fix For: 7.3
>
> Attachments: LUCENE-8182.patch, LUCENE-8182.patch, LUCENE-8182.patch
>
>
> BoostingQuery applies the parent query boost instead of the boost set on the 
> query due to a name clash in the anonymous class created by the createWeight 
> method.



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

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



[jira] [Created] (SOLR-12049) Solrj doesn't pass basic auth for delete requests

2018-03-01 Thread Nikolay Martynov (JIRA)
Nikolay Martynov created SOLR-12049:
---

 Summary: Solrj doesn't pass basic auth for delete requests
 Key: SOLR-12049
 URL: https://issues.apache.org/jira/browse/SOLR-12049
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 7.1
Reporter: Nikolay Martynov


If basic authentication is used then delete by id requests do not work because 
authentication parameters are not passed.

For updates there is this line in the code: 
https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L280

For deletes there is no corresponding logic in the same file below.



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

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



[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Shinichiro Abe (JIRA)

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

Shinichiro Abe commented on SOLR-11795:
---

latest patch, there still be 'yaml' word in adoc.
It's just my question, as to argparse4j dependency, why not use DOMUtil or 
common.util.Util.etc that's already used by other places in Solr?

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-2.patch, 
> SOLR-11795-3.patch, SOLR-11795-4.patch, SOLR-11795-5.patch, 
> SOLR-11795-6.patch, SOLR-11795-7.patch, SOLR-11795-8.patch, 
> SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, SOLR-11795.patch, 
> solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[JENKINS-EA] Lucene-Solr-6.6-Linux (64bit/jdk-10-ea+43) - Build # 179 - Still Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/179/
Java: 64bit/jdk-10-ea+43 -XX:-UseCompressedOops -XX:+UseSerialGC

70 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.OverseerCollectionConfigSetProcessorTest

Error Message:
 Mockito cannot mock this class: class org.apache.solr.cloud.OverseerTaskQueue. 
 Mockito can only mock non-private & non-final classes. If you're not sure why 
you're getting this error, please report to the mailing list.   Java
   : 10 JVM vendor name: "Oracle Corporation" JVM vendor version : 10+43 
JVM name   : OpenJDK 64-Bit Server VM JVM version: 10+43 JVM 
info   : mixed mode OS name: Linux OS version : 
4.13.0-36-generic   Underlying exception : 
java.lang.UnsupportedOperationException: Cannot define class using reflection

Stack Trace:
org.mockito.exceptions.base.MockitoException: 
Mockito cannot mock this class: class org.apache.solr.cloud.OverseerTaskQueue.

Mockito can only mock non-private & non-final classes.
If you're not sure why you're getting this error, please report to the mailing 
list.


Java   : 10
JVM vendor name: "Oracle Corporation"
JVM vendor version : 10+43
JVM name   : OpenJDK 64-Bit Server VM
JVM version: 10+43
JVM info   : mixed mode
OS name: Linux
OS version : 4.13.0-36-generic


Underlying exception : java.lang.UnsupportedOperationException: Cannot define 
class using reflection
at __randomizedtesting.SeedInfo.seed([8F6D1A7BE32BB9D5]:0)
at 
org.apache.solr.cloud.OverseerCollectionConfigSetProcessorTest.setUpOnce(OverseerCollectionConfigSetProcessorTest.java:103)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.UnsupportedOperationException: Cannot define class using 
reflection
at 
net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection$Dispatcher$Unavailable.defineClass(ClassInjector.java:819)
at 
net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection.inject(ClassInjector.java:183)
at 
net.bytebuddy.dynamic.loading.ClassLoadingStrategy$Default$InjectionDispatcher.load(ClassLoadingStrategy.java:187)
at 
net.bytebuddy.dynamic.TypeResolutionStrategy$Passive.initialize(TypeResolutionStrategy.java:79)
at 
net.bytebuddy.dynamic.DynamicType$Default$Unloaded.load(DynamicType.java:4352)
at 
org.mockito.internal.creation.bytebuddy.SubclassBytecodeGenerator.mockClass(SubclassBytecodeGenerator.java:94)
at 

[JENKINS] Lucene-Solr-Tests-6.6 - Build # 44 - Failure

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.6/44/

All tests passed

Build Log:
[...truncated 10549 lines...]
[javac] Compiling 1088 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/solr/build/solr-core/classes/java
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/solr/core/src/java/org/apache/solr/core/CoreContainer.java:1557:
 error: cannot find symbol
[javac] DocCollection coll = 
getZkController().getZkStateReader().getClusterState().getCollection(cd.getCollectionName());
[javac] ^
[javac]   symbol:   class DocCollection
[javac]   location: class CoreContainer
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/build.xml:775: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/build.xml:719: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/build.xml:59: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/solr/build.xml:267: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/solr/common-build.xml:549:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/solr/common-build.xml:497:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/solr/common-build.xml:398:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/lucene/common-build.xml:535:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.6/lucene/common-build.xml:2007:
 Compile failed; see the compiler error output for details.

Total time: 22 minutes 42 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/468/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

Error Message:
Error from server at 
http://127.0.0.1:48467/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 404 
Can not find: /solr/testcollection_shard1_replica_n2/update  
HTTP ERROR 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:48467/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/testcollection_shard1_replica_n2/update

HTTP ERROR 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: 
/solr/testcollection_shard1_replica_n2/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121




at 
__randomizedtesting.SeedInfo.seed([39E8CA3FF88CF65E:9A12649A7F641CFB]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 

[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-11503:


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

SOLR-11503: Collections created with legacyCloud=true cannot be opened if 
legacyCloud=false


> Collections created with legacyCloud=true cannot be opened if 
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, 
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a 
> collection with legacyCloud=true then switch to legacyCloud=false, you get an 
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1 
> and 7.x, this means that any attempt to upgrade Solr with existing 
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value 
> for legacyCloud is used in both. Collections created with 6.6.0 would work. 
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the 
> default legacyCloud=false is present when the core is created, properties are 
> persisted with coreNodeName. However, if someone switches legacyCloud to 
> true, then creates a collection, then changes legacyCloud back to false then 
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls 
> below. coreNodeName is added to the descriptor in 
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so 
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in 
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary 
> patch w/o tests in a bit for discussion, but the question is really what to 
> do about 6.6.1 and 6.6.2 and 7.1 for that matter. 
> This is compounded by the fact that with the CVE, there's strong incentive to 
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to 
> ZK and getting it (and persisting it). Haven't worked that part out yet 
> though, not in the first patch. Note one point here if it works as I hope it 
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they 
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and 
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start 
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud=true until then.
> > Backport to point releases like 7.1.1? 6.6.3?
> > and what about 7.0? I don't think many people will be affected by 7.0 since 
> > 7.1 came out so soon after. And setting legacyCloud=true will let people 
> > get by.
> Fixing the two parts is not a question, they both need to be fixed. The real 
> question is whether we need to create a point release that incorporates one 
> or both or whether saying "you must set legacyCloud=true prior to Solr 
> version 7.# in order to work with any collections created with Solr versions 
> 6.6.1 through 7.#".
> Let's hear opinions..



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

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



[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

2018-03-01 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-8189:
---

There is already a check in common-build for a workaround. We can fail the same 
way.

> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> 

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

2018-03-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-11843:
-

bq. If you don't have time, I could fix the CHANGES entry and commit it.

Go for it.  I've been busy lately and haven't had time beyond writing comments 
and replying to select emails.

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-11843.patch, SOLR-11843.patch
>
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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



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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21560/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=14163, name=jetty-launcher-5090-thread-1-EventThread, state=WAITING, 
group=TGRP-TestSolrCloudWithSecureImpersonation] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
2) Thread[id=14162, 
name=jetty-launcher-5090-thread-1-SendThread(127.0.0.1:46343), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)   
  at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=14163, name=jetty-launcher-5090-thread-1-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
   2) Thread[id=14162, 
name=jetty-launcher-5090-thread-1-SendThread(127.0.0.1:46343), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)
at __randomizedtesting.SeedInfo.seed([A3F0FF4FF24938B3]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=14162, name=jetty-launcher-5090-thread-1-SendThread(127.0.0.1:46343), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)   
  at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=14162, 
name=jetty-launcher-5090-thread-1-SendThread(127.0.0.1:46343), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)
at __randomizedtesting.SeedInfo.seed([A3F0FF4FF24938B3]:0)




Build Log:
[...truncated 12668 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_A3F0FF4FF24938B3-001/init-core-data-001
   [junit4]   2> 440035 WARN  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[A3F0FF4FF24938B3]-worker) [   
 ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=20 numCloses=20
   [junit4]   2> 440035 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[A3F0FF4FF24938B3]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 440036 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[A3F0FF4FF24938B3]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 440036 INFO  

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

2018-03-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on LUCENE-8189:
--

bq. add a check for the exact ANT version 

Good idea.  Have it check the versions of all relevant tools and fail with a 
helpful message if they are outside of the range that we consider acceptable.


> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> 

RE: Tests failing over the last day or so

2018-03-01 Thread Uwe Schindler
Ah sorry,

misunderstood. So the RM has to only apply the version update on the release 
branch. And in master and 7.x after release.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Steve Rowe [mailto:sar...@gmail.com]
> Sent: Thursday, March 1, 2018 7:54 PM
> To: Lucene Dev 
> Subject: Re: Tests failing over the last day or so
> 
> 
> > On Mar 1, 2018, at 1:32 PM, Uwe Schindler  wrote:
> >
> > Hi,
> >
> > I think that's a bug in the test that should be fixed. In the past we had 
> > some
> extra check about "release branches" in it, which seems to no longer work.
> >
> > IMHO, one a release is done, the release branch should switch to the next
> version asap.
> 
> +1
> 
> > -1 to revert the changes in branch_6_6
> 
> Right, I didn’t revert on branch_6_6.
> 
> --
> Steve
> www.lucidworks.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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



[jira] [Commented] (SOLR-12048) Cannot index formatted mail

2018-03-01 Thread Tim Allison (JIRA)

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

Tim Allison commented on SOLR-12048:


Sorry...didn't realize MailEntityProcessor is not using Tika for the main body 
processing...looking through MEP now...

> Cannot index formatted mail
> ---
>
> Key: SOLR-12048
> URL: https://issues.apache.org/jira/browse/SOLR-12048
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: Dimitris
>Priority: Major
> Attachments: index_no_content.txt, index_success.txt
>
>
> Using /example/example-DIH/solr/mail/ configuration, a gmail mailbox has been 
> indexed. Nevertheless, only plain text mails are indexed. Formatted content 
> is not indexed.



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

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



[jira] [Comment Edited] (SOLR-12048) Cannot index formatted mail

2018-03-01 Thread Tim Allison (JIRA)

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

Tim Allison edited comment on SOLR-12048 at 3/1/18 8:55 PM:


Or probably u...@tika.apache.org :)

+1 to closing this issue and moving the discussion to the Solr user list.

In Tika <=1.17, these alternate bodies were treated as attachments, and we've 
fixed this for 1.18.

Make sure to change {{processAttachement}} to true if you haven't!

from {{mail-data-config.xml}}
{noformat}
 
{noformat}


was (Author: talli...@mitre.org):
Or probably u...@tika.apache.org :)

In Tika <=1.17, these alternate bodies were treated as attachments, and we've 
fixed this for 1.18.

Make sure to change {{processAttachement}} to true if you haven't!

from {{mail-data-config.xml}}
{noformat}
 
{noformat}

> Cannot index formatted mail
> ---
>
> Key: SOLR-12048
> URL: https://issues.apache.org/jira/browse/SOLR-12048
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: Dimitris
>Priority: Major
> Attachments: index_no_content.txt, index_success.txt
>
>
> Using /example/example-DIH/solr/mail/ configuration, a gmail mailbox has been 
> indexed. Nevertheless, only plain text mails are indexed. Formatted content 
> is not indexed.



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

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



[jira] [Commented] (SOLR-12048) Cannot index formatted mail

2018-03-01 Thread Tim Allison (JIRA)

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

Tim Allison commented on SOLR-12048:


Or probably u...@tika.apache.org :)

In Tika <=1.17, these alternate bodies were treated as attachments, and we've 
fixed this for 1.18.

Make sure to change {{processAttachement}} to true if you haven't!

from {{mail-data-config.xml}}
{noformat}
 
{noformat}

> Cannot index formatted mail
> ---
>
> Key: SOLR-12048
> URL: https://issues.apache.org/jira/browse/SOLR-12048
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: Dimitris
>Priority: Major
> Attachments: index_no_content.txt, index_success.txt
>
>
> Using /example/example-DIH/solr/mail/ configuration, a gmail mailbox has been 
> indexed. Nevertheless, only plain text mails are indexed. Formatted content 
> is not indexed.



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

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



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

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/2/

4 tests failed.
FAILED:  org.apache.solr.ltr.TestLTRReRankingPipeline.testDifferentTopN

Error Message:
expected:<1.0> but was:<0.0>

Stack Trace:
java.lang.AssertionError: expected:<1.0> but was:<0.0>
at 
__randomizedtesting.SeedInfo.seed([ADF49C77C6243E25:5C55EE27F39FF4B7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:443)
at org.junit.Assert.assertEquals(Assert.java:512)
at 
org.apache.solr.ltr.TestLTRReRankingPipeline.testDifferentTopN(TestLTRReRankingPipeline.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.ZkControllerTest.testPublishAndWaitForDownStates

Error Message:
The ZkController.publishAndWaitForDownStates should have timed out but it didn't

Stack Trace:
java.lang.AssertionError: The ZkController.publishAndWaitForDownStates should 
have timed out but it didn't
at 
__randomizedtesting.SeedInfo.seed([E1D4D541C688ADB6:C6DBB9AD671FE289]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 

[jira] [Commented] (SOLR-11843) Admin UI -- collection creation sends routerField parameter instead of router.field

2018-03-01 Thread Cassandra Targett (JIRA)

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

Cassandra Targett commented on SOLR-11843:
--

[~elyograg] - were you planning to try to get this in for 7.3? I just applied 
your patch & besides a little conflict from CHANGES, it looks good and when I 
create a new collection, I see this (irrelevant params omitted):

{code}
Invoked Collection Action :create with params 
...=text...=compositeId...
{code}

So +1 from me. If you don't have time, I could fix the CHANGES entry and commit 
it.

> Admin UI -- collection creation sends routerField parameter instead of 
> router.field
> ---
>
> Key: SOLR-11843
> URL: https://issues.apache.org/jira/browse/SOLR-11843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-11843.patch, SOLR-11843.patch
>
>
> One of the important fields for collection creation is the router.field 
> parameter.  This shows up in the admin UI as "routerField" and when you enter 
> a value there, the admin UI sends this information in the collections API 
> request as a parameter named routerField ... but it should be sent as 
> "router.field" instead.



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

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



[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+43) - Build # 1454 - Still Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1454/
Java: 64bit/jdk-10-ea+43 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([A45B71578D29D114:7C165C007AF474B4]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:97)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

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

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/967/

No tests ran.

Build Log:
[...truncated 28738 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (39.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 30.2 MB in 0.03 sec (1178.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 73.2 MB in 0.07 sec (995.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 83.7 MB in 0.08 sec (1049.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.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.badapples=false 
-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] test demo with 9...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 9...
   [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.00 sec (256.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 52.6 MB in 0.06 sec (890.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 151.0 MB in 0.18 sec (856.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 152.0 MB in 0.16 sec (974.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.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=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 

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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1706/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
4 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=14020, name=jetty-launcher-2795-thread-1-EventThread, state=WAITING, 
group=TGRP-TestSolrCloudWithSecureImpersonation] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
2) Thread[id=14018, name=jetty-launcher-2795-thread-2-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
3) Thread[id=14019, 
name=jetty-launcher-2795-thread-1-SendThread(127.0.0.1:44826), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)   
  at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)   
 4) Thread[id=14017, 
name=jetty-launcher-2795-thread-2-SendThread(127.0.0.1:44826), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at java.lang.Thread.sleep(Native Method) at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)   
  at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 4 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=14020, name=jetty-launcher-2795-thread-1-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
   2) Thread[id=14018, name=jetty-launcher-2795-thread-2-EventThread, 
state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)
   3) Thread[id=14019, 
name=jetty-launcher-2795-thread-1-SendThread(127.0.0.1:44826), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)
   4) Thread[id=14017, 
name=jetty-launcher-2795-thread-2-SendThread(127.0.0.1:44826), 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
at 
org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)
at __randomizedtesting.SeedInfo.seed([CA3465D8D0D03170]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=14019, name=jetty-launcher-2795-thread-1-SendThread(127.0.0.1:44826), 
state=TIMED_WAITING, 

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12028:


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

SOLR-12028: BadApple and AwaitsFix annotations usage

(cherry picked from commit b732f06)


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



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

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



[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

2018-03-01 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12028:


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

SOLR-12028: BadApple and AwaitsFix annotations usage


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



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

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



Re: Code Reviews

2018-03-01 Thread Stefan Matheis
> This seems to be what the majority thinks and I see the point, I’m
concerned of this myself. I’m just not sure how to encourage people to
submit for review and review other peoples more since the option is there
now and is not very frequently used. I’m open to suggestions if anyone has
ideas.

It's not an easy thing to apply and the details are maybe a bit witty ..
I've seen a budget/credit system in use. Where you earn points doing
reviews .. which are basically needed to get something in _without_ a
review.

I'm not proposing exactly that, because I don't like the incentive it's
using .. just the underlying system is appealing. Sometimes you need a
little bit more than just say please.

Perhaps picking up what Shawn mentioned: if you could "subscribe" to
certain parts of the code and get notified about patches that are related
to it? Obviously that's not a perfect solution by itself either (because it
could potentially mean that people are only just looking at those anymore
and none of the others) ..

But it's what some git(hub)-based review systems use: they @-mention you in
a upcoming change because you touched that code at least once before. So
you are kind of a good fit to review it.

... Uhm okay, that was not as straight forward as I'd like my reply to be -
hopefully it still helps :)

Best
Stefan

On Mar 1, 2018 4:59 AM, "Tomas Fernandez Lobbe"  wrote:


Like Dawid I hope we won't add strict requirements to get changes reviewed
before merging but I do agree with the general sentiment that reviews are
helpful and improve code quality.

This seems to be what the majority thinks and I see the point, I’m
concerned of this myself. I’m just not sure how to encourage people to
submit for review and review other peoples more since the option is there
now and is not very frequently used. I’m open to suggestions if anyone has
ideas.

I really appreciate getting feedback on patches that I upload, including
negative feedback and I don't mind being pinged on issues if anyone thinks
I might have valuable feedback to give.

Exactly, same here. The times I got my patches reviewed and I got very
valuable feedback, including someone fixing something broken in my patch.

I encourage people to go and review some random commits and see if they
could have given any valuable feedback. Someone could tell me “you can go,
review, and create a new Jira with your proposed changes”, but that doesn’t
happen usually, so back to my point.


On Feb 28, 2018, at 5:11 PM, Adrien Grand  wrote:

Like Dawid I hope we won't add strict requirements to get changes reviewed
before merging but I do agree with the general sentiment that reviews are
helpful and improve code quality. I really appreciate getting feedback on
patches that I upload, including negative feedback and I don't mind being
pinged on issues if anyone thinks I might have valuable feedback to give.

I didn't know Solr had a CTR policy. I understand CTR and RTC have pros and
cons but since there seems to be agreement that we want more changes to be
reviewed I think RTC is better at encouraging a review culture: as a
reviewer it's easier to recommend that the change should be done in a
totally different way if that is what you think, and you also feel more
useful since someone considered that the change needs your pair of eyes
before being merged.

Le mer. 28 févr. 2018 à 21:07, Cassandra Targett  a
écrit :

> On Wed, Feb 28, 2018 at 1:58 PM, Shawn Heisey  wrote:
>
>>
>> I notice in ZK issues that projects associated with Hadoop have an
>> *automatic* machine-generated QA check whenever a patch is submitted on
>> those projects.  This obviously is not the same as a real review by a
>> person, but the info it outputs seems useful.
>>
>>
>>
> This is what SOLR-10912 intends to achieve.
>
>


[JENKINS] Lucene-Solr-6.6-Linux (64bit/jdk1.8.0_162) - Build # 178 - Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/178/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([642A65D5A4DF2016:EF0DB604E5D98B92]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

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

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2395/

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

Error Message:
Two TriggerAction instances should have been created by now

Stack Trace:
java.lang.AssertionError: Two TriggerAction instances should have been created 
by now
at 
__randomizedtesting.SeedInfo.seed([7742CEF72186DB1B:5CBD1BACBBFECECB]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeLostTriggerRestoreState(TestTriggerIntegration.java:305)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12046 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
   [junit4]   2> 6652 INFO  
(SUITE-TestTriggerIntegration-seed#[7742CEF72186DB1B]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 

Re: Tests failing over the last day or so

2018-03-01 Thread Steve Rowe

> On Mar 1, 2018, at 1:32 PM, Uwe Schindler  wrote:
> 
> Hi,
> 
> I think that's a bug in the test that should be fixed. In the past we had 
> some extra check about "release branches" in it, which seems to no longer 
> work.
> 
> IMHO, one a release is done, the release branch should switch to the next 
> version asap.

+1

> -1 to revert the changes in branch_6_6

Right, I didn’t revert on branch_6_6.

--
Steve
www.lucidworks.com


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



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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/481/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested

Error Message:
Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs 

Stack Trace:
java.lang.AssertionError: Missing backcompat test files:
  6.6.3-cfs
  7.2.1-cfs

at 
__randomizedtesting.SeedInfo.seed([1FCA08E300256947:F15E7A3B4B27F6B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested(TestBackwardsCompatibility.java:633)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested

Error Message:
Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs 

Stack Trace:
java.lang.AssertionError: Missing backcompat test files:
  6.6.3-cfs
  7.2.1-cfs

at 
__randomizedtesting.SeedInfo.seed([1FCA08E300256947:F15E7A3B4B27F6B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested(TestBackwardsCompatibility.java:633)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

2018-03-01 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-8189:
---

As Adrien said, this is a well-known bug. We cannot work around it.

We might only add a check for the exact ANT version to our common-build.xml 
that fails early with a message "don't user ANT 1.10.2"

> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> 

Re: Tests failing over the last day or so

2018-03-01 Thread Erick Erickson
Steve:

It's not a problem as far as I'm concerned that needs immediate
attention so it's fine to get to it "sometime"..

On Thu, Mar 1, 2018 at 10:23 AM, Steve Rowe  wrote:
>
>> On Mar 1, 2018, at 12:34 PM, Erick Erickson  wrote:
>> Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs:
>> org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested
>
> I caused this by running addVersion.py for 6.6.3 on branch_6_6, branch_6x, 
> branch_7x, and master and then committing and pushing the changes (that’s 
> what ReleaseToDo says to do).  Not sure why 7.2.1-cfs is on ^^ that list, 
> probably (just) a reporting bug (since index.7.2.1-cfs.zip is present).  I’ll 
> revert for now on non-release branches, and modify the ReleaseToDo to delay 
> addVersion.py on non-release branches, to be run as a post-release task.
>
> --
> Steve
> www.lucidworks.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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



RE: Tests failing over the last day or so

2018-03-01 Thread Uwe Schindler
Hi,

I think that's a bug in the test that should be fixed. In the past we had some 
extra check about "release branches" in it, which seems to no longer work.

IMHO, one a release is done, the release branch should switch to the next 
version asap.

-1 to revert the changes in branch_6_6

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Steve Rowe [mailto:sar...@gmail.com]
> Sent: Thursday, March 1, 2018 7:24 PM
> To: Lucene Dev 
> Subject: Re: Tests failing over the last day or so
> 
> 
> > On Mar 1, 2018, at 12:34 PM, Erick Erickson 
> wrote:
> > Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs:
> >
> org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested
> 
> I caused this by running addVersion.py for 6.6.3 on branch_6_6, branch_6x,
> branch_7x, and master and then committing and pushing the changes (that’s
> what ReleaseToDo says to do).  Not sure why 7.2.1-cfs is on ^^ that list,
> probably (just) a reporting bug (since index.7.2.1-cfs.zip is present).  I’ll
> revert for now on non-release branches, and modify the ReleaseToDo to
> delay addVersion.py on non-release branches, to be run as a post-release
> task.
> 
> --
> Steve
> www.lucidworks.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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



Re: Tests failing over the last day or so

2018-03-01 Thread Steve Rowe

> On Mar 1, 2018, at 12:34 PM, Erick Erickson  wrote:
> Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs:
> org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested

I caused this by running addVersion.py for 6.6.3 on branch_6_6, branch_6x, 
branch_7x, and master and then committing and pushing the changes (that’s what 
ReleaseToDo says to do).  Not sure why 7.2.1-cfs is on ^^ that list, probably 
(just) a reporting bug (since index.7.2.1-cfs.zip is present).  I’ll revert for 
now on non-release branches, and modify the ReleaseToDo to delay addVersion.py 
on non-release branches, to be run as a post-release task.

--
Steve
www.lucidworks.com


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



[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

2018-03-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on LUCENE-8189:
--

On a solr-user thread that prompted me to file this issue, [~erickoerickson] 
mentioned that 1.10.1 works.  So this might indeed be a bug in ant.  I only 
tried 1.10.2.

I hadn't gotten around to replying to the mailing list thread yet.


> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 

[jira] [Resolved] (LUCENE-8189) Build fails with ant version 1.10.x

2018-03-01 Thread Adrien Grand (JIRA)

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

Adrien Grand resolved LUCENE-8189.
--
Resolution: Invalid

Hello Shawn. This is an Ant bug indeed: 
http://markmail.org/message/wshnt7ok2rlvy5w7.

> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> 

[jira] [Commented] (LUCENE-8189) Build fails with ant version 1.10.x

2018-03-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on LUCENE-8189:
--

Looked for a previous issue on this, didn't find one.  If this is a duplicate, 
feel free to close as a duplicate.

Although it's always possible that this is a bug in Ant, that seems unlikely.  
Version 1.10 has been out for more than a year, and is on its third point 
release.


> Build fails with ant version 1.10.x
> ---
>
> Key: LUCENE-8189
> URL: https://issues.apache.org/jira/browse/LUCENE-8189
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Affects Versions: master (8.0)
>Reporter: Shawn Heisey
>Priority: Minor
>
> Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
> NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
> everything's fine.
> {noformat}
> C:\Users\sheisey\git\lucene-solr>ant clean
> Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml
> BUILD FAILED
> C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
> while executing this line:
> C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at java.util.stream.Stream.of(Stream.java:1000)
> at 
> java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
> at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at 
> java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
> at 
> org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
> at 
> org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
> at 
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
> at 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at 
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at 
> java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at 
> java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> at 
> org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
> at 
> org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:346)
> at org.apache.tools.ant.Target.execute(Target.java:448)
> at 
> org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
> at 
> org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at 

[jira] [Created] (LUCENE-8189) Build fails with ant version 1.10.x

2018-03-01 Thread Shawn Heisey (JIRA)
Shawn Heisey created LUCENE-8189:


 Summary: Build fails with ant version 1.10.x
 Key: LUCENE-8189
 URL: https://issues.apache.org/jira/browse/LUCENE-8189
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Affects Versions: master (8.0)
Reporter: Shawn Heisey


Any action I try to take with ANT_HOME set to the 1.10.2 version fails with a 
NullPointerException.  If I revert back to ANT_HOME pointing at 1.9, 
everything's fine.

{noformat}
C:\Users\sheisey\git\lucene-solr>ant clean
Buildfile: C:\Users\sheisey\git\lucene-solr\build.xml

BUILD FAILED
C:\Users\sheisey\git\lucene-solr\build.xml:21: The following error occurred 
while executing this line:
C:\Users\sheisey\git\lucene-solr\lucene\common-build.xml:623: 
java.lang.NullPointerException
at java.util.Arrays.stream(Arrays.java:5004)
at java.util.stream.Stream.of(Stream.java:1000)
at 
java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:267)
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at 
java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
at 
java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
at 
java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
at 
org.apache.tools.ant.util.ChainedMapper.lambda$mapFileName$1(ChainedMapper.java:36)
at java.util.stream.ReduceOps$1ReducingSink.accept(ReduceOps.java:80)
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at 
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:484)
at 
org.apache.tools.ant.util.ChainedMapper.mapFileName(ChainedMapper.java:35)
at 
org.apache.tools.ant.util.CompositeMapper.lambda$mapFileName$0(CompositeMapper.java:32)
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
at 
java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
at 
java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
at 
org.apache.tools.ant.util.CompositeMapper.mapFileName(CompositeMapper.java:33)
at 
org.apache.tools.ant.taskdefs.PathConvert.execute(PathConvert.java:363)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:346)
at org.apache.tools.ant.Target.execute(Target.java:448)
at 
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:172)
at 
org.apache.tools.ant.taskdefs.ImportTask.importResource(ImportTask.java:221)
at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:165)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
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 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:346)
at org.apache.tools.ant.Target.execute(Target.java:448)
at 
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:183)
at 
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
   

[jira] [Commented] (SOLR-12048) Cannot index formatted mail

2018-03-01 Thread Cassandra Targett (JIRA)

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

Cassandra Targett commented on SOLR-12048:
--

It feels to me like this issue should really be raised on the solr-user mailing 
list before we assume there is a bug that someone needs to fix in DIH: 
https://lucene.apache.org/solr/community.html#mailing-lists-irc

> Cannot index formatted mail
> ---
>
> Key: SOLR-12048
> URL: https://issues.apache.org/jira/browse/SOLR-12048
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: Dimitris
>Priority: Major
> Attachments: index_no_content.txt, index_success.txt
>
>
> Using /example/example-DIH/solr/mail/ configuration, a gmail mailbox has been 
> indexed. Nevertheless, only plain text mails are indexed. Formatted content 
> is not indexed.



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

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



[JENKINS] Lucene-Solr-Tests-6.6 - Build # 43 - Still unstable

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.6/43/

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Something is broken in the assert for no shards using the same indexDir - 
probably something was changed in the attributes published in the MBean of 
SolrCore : {}

Stack Trace:
java.lang.AssertionError: Something is broken in the assert for no shards using 
the same indexDir - probably something was changed in the attributes published 
in the MBean of SolrCore : {}
at 
__randomizedtesting.SeedInfo.seed([E754C01620BF8B9A:AF21B4A2268CA40F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.checkNoTwoShardsUseTheSameIndexDir(CollectionsAPIDistributedZkTest.java:646)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:524)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

Tests failing over the last day or so

2018-03-01 Thread Erick Erickson
I'll BadApple these four unless there are objections. I know there's
active work being done on the TriggerIntergrationTests, should we
leave those in for the nonce? Or has anything been checked in for
TriggerIntergrationTest (those were from from day before yesterday).

org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testNodeMarkersRegistration
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testSearchRate
org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest
org.apache.solr.cloud.hdfs.HdfsTlogReplayBufferedWhileIndexingTest.test

Windows failures:

I'm inclined to _not_ BadApple these, just ignore them rather than
reduce test coverage for Unix. I'm thinking here that we'll treat
Windows failures as a separate issue, maybe raise a Windows-specific
JIRA? Any other suggestions? As for test failures on Windows that do
_not_ mention filesystem issues for the time being I'll wait until we
get a non-Windows failure before BadApple-ing them.

Dawid suggests the Windows failures may be due to not closing files,
and they're valid in that sense but the files are in the temp
directory so _probably_ not an issue with a live installation.

Could not remove files (spot checking this is indeed a problem with
temp directories):
junit.framework.TestSuite.org.apache.lucene.analysis.core.TestRandomChains
junit.framework.TestSuite.org.apache.lucene.codecs.lucene50.TestLucene50StoredFieldsFormat
junit.framework.TestSuite.org.apache.lucene.index.TestLongPostings
org.apache.lucene.replicator.IndexReplicationClientTest.testNoUpdateThread
junit.framework.TestSuite.org.apache.lucene.codecs.compressing.TestCompressingTermVectorsFormat
junit.framework.TestSuite.org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud
junit.framework.TestSuite.org.apache.solr.schema.TestUseDocValuesAsStored2
junit.framework.TestSuite.org.apache.solr.search.TestGraphTermsQParserPlugin
junit.framework.TestSuite.org.apache.solr.update.SolrCmdDistributorTest
junit.framework.TestSuite.org.apache.solr.update.processor.TestNamedUpdateProcessors
org.apache.lucene.replicator.IndexReplicationClientTest.testConsistencyOnExceptions


These errors may or may not have anything to do with Windows file systems.


Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs:
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested


No live SolrServers available:
org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove


Something is broken in the assert for no shards using the same
indexDir - probably something was changed in the attributes published
in the MBean of SolrCore:
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI


Timed out waiting for overseer state change:
org.apache.solr.cloud.OverseerRolesTest.testOverseerRole

Erick

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



[jira] [Resolved] (SOLR-12046) TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory fails on every windows build on jenkins.thetaphi.de ?

2018-03-01 Thread Hoss Man (JIRA)

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

Hoss Man resolved SOLR-12046.
-
   Resolution: Fixed
Fix Version/s: 7.3
   master (8.0)

both the 7.x and master jenkins jobs have run a single build since my commit, 
and in both of those builds this test passed -- so i'm calling this resolved.

> TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory fails on every windows 
> build on jenkins.thetaphi.de ? 
> 
>
> Key: SOLR-12046
> URL: https://issues.apache.org/jira/browse/SOLR-12046
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory has a fairly modest 
> failures rate over the past 7 days of ~5% -- but if you drill down and look 
> at the failures there is a very obvious pattern:
> * all of the failures are at the suite level
> * every failure is on jenkins.thetaphi.de
> * every failure is on Windows
> * failures are 50/50 master and branch_7x
> A quick glance at a single recent failure (i haven't dug in depth to others 
> over history) shows that something about the test setup appears to be 
> preventing the normal file cleanup from working...
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory 
> -Dtests.seed=1C7DCF1E2889E5C6 -Dtests.slow=true -Dtests.locale=sr-BA 
> -Dtests.timezone=America/Monterrey -Dtests.asserts=true 
> -Dtests.file.encoding=Cp1252
>[junit4] ERROR   0.00s J1 | 
> TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory (suite) <<<
>[junit4]> Throwable #1: java.io.IOException: Could not remove the 
> following files (in the order of attempts):
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1\conf:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1\conf
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001:
>  java.nio.file.DirectoryNotEmptyException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1\conf\en-test-sent.bin:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1\conf\en-test-sent.bin
>[junit4]>
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1\conf\en-test-tokenizer.bin:
>  java.nio.file.AccessDeniedException: 
> C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-analysis-extras\test\J1\temp\solr.update.processor.TestOpenNLPExtractNamedEntitiesUpdateProcessorFactory_1C7DCF1E2889E5C6-001\tempDir-001\collection1\conf\en-test-tokenizer.bin
>[junit4]>
> 

[jira] [Commented] (SOLR-11336) DocBasedVersionConstraintsProcessor should be more extensible and support multiple version fields

2018-03-01 Thread Michael Braun (JIRA)

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

Michael Braun commented on SOLR-11336:
--

Ran test suite last night and looks good! (Aside from known unrelated bad apple 
tests)

> DocBasedVersionConstraintsProcessor should be more extensible and support 
> multiple version fields
> -
>
> Key: SOLR-11336
> URL: https://issues.apache.org/jira/browse/SOLR-11336
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0)
>Reporter: Michael Braun
>Priority: Minor
> Attachments: SOLR-11336.patch, SOLR-11336.patch, SOLR-11336.patch
>
>
> DocBasedVersionConstraintsProcessor supports allowing document updates only 
> if the new version is greater than the old. However, if any behavior wants to 
> be extended / changed in minor ways, the entire class will need to be copied 
> and slightly modified rather than extending and changing the method in 
> question. 
> It would be nice if DocBasedVersionConstraintsProcessor stood on its own as a 
> non-private class. In addition, certain methods (such as pieces of 
> isVersionNewEnough) should be broken out into separate methods so they can be 
> extended such that someone can extend the processor class and override what 
> it means for a new version to be accepted (allowing equal versions through? 
> What if new is a lower not greater number?). 



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

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



[jira] [Commented] (SOLR-12048) Cannot index formatted mail

2018-03-01 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-12048:
---

If you can find the problem and provide a patch that would be great. This is 
intended to be an example though, so being able to handle arbitrary e-mails is 
not guaranteed at all.

> Cannot index formatted mail
> ---
>
> Key: SOLR-12048
> URL: https://issues.apache.org/jira/browse/SOLR-12048
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: Dimitris
>Priority: Major
> Attachments: index_no_content.txt, index_success.txt
>
>
> Using /example/example-DIH/solr/mail/ configuration, a gmail mailbox has been 
> indexed. Nevertheless, only plain text mails are indexed. Formatted content 
> is not indexed.



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

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



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

2018-03-01 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-repro/170/

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

[repro] Revision: 6e79bc7d5c6b0fafe27ea732ece403dd3807d673

[repro] Repro line:  ant test  -Dtestcase=TestLargeCluster 
-Dtests.method=testSearchRate -Dtests.seed=CCE5A1A44013B8C5 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=pt-BR -Dtests.timezone=America/Mexico_City -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestJmxIntegration 
-Dtests.method=testJmxOnCoreReload -Dtests.seed=CCE5A1A44013B8C5 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=sr-Latn -Dtests.timezone=US/Aleutian -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=AutoscalingHistoryHandlerTest 
-Dtests.method=testHistory -Dtests.seed=CCE5A1A44013B8C5 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=no 
-Dtests.timezone=America/Rosario -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.method=doTestIndexAndConfigReplication -Dtests.seed=CCE5A1A44013B8C5 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=tr 
-Dtests.timezone=America/Vancouver -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=CCE5A1A44013B8C5 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=tr 
-Dtests.timezone=America/Vancouver -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ZkControllerTest 
-Dtests.method=testPublishAndWaitForDownStates -Dtests.seed=CCE5A1A44013B8C5 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=en-US -Dtests.timezone=CTT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestLTRReRankingPipeline 
-Dtests.method=testDifferentTopN -Dtests.seed=A7543ECFE5AA6D0 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=und -Dtests.timezone=Indian/Chagos -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
373ed8cf743db9442575e60d2c981a5c9dec0a93
[repro] git fetch
[repro] git checkout 6e79bc7d5c6b0fafe27ea732ece403dd3807d673

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

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

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   AutoscalingHistoryHandlerTest
[repro]   TestJmxIntegration
[repro]   TestReplicationHandler
[repro]   TestLargeCluster
[repro]   ZkControllerTest
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro] ant compile-test

[...truncated 3310 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=25 
-Dtests.class="*.AutoscalingHistoryHandlerTest|*.TestJmxIntegration|*.TestReplicationHandler|*.TestLargeCluster|*.ZkControllerTest"
 -Dtests.showOutput=onerror  -Dtests.seed=CCE5A1A44013B8C5 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=no 
-Dtests.timezone=America/Rosario -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] ant compile-test

[...truncated 566 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLTRReRankingPipeline" -Dtests.showOutput=onerror  
-Dtests.seed=A7543ECFE5AA6D0 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=und -Dtests.timezone=Indian/Chagos 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster
[repro]   5/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   5/5 failed: org.apache.solr.core.TestJmxIntegration
[repro]   5/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro]   5/5 failed: 
org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest
[repro]   5/5 failed: org.apache.solr.ltr.TestLTRReRankingPipeline

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

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   AutoscalingHistoryHandlerTest
[repro]   TestJmxIntegration
[repro]   TestReplicationHandler
[repro]   ZkControllerTest
[repro]solr/contrib/ltr
[repro]   TestLTRReRankingPipeline
[repro] ant compile-test

[...truncated 3310 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 

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

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1453/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested

Error Message:
Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs 

Stack Trace:
java.lang.AssertionError: Missing backcompat test files:
  6.6.3-cfs
  7.2.1-cfs

at 
__randomizedtesting.SeedInfo.seed([94F8C6D1C313A305:842729917784B529]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested(TestBackwardsCompatibility.java:633)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested

Error Message:
Missing backcompat test files:   6.6.3-cfs   7.2.1-cfs 

Stack Trace:
java.lang.AssertionError: Missing backcompat test files:
  6.6.3-cfs
  7.2.1-cfs

at 
__randomizedtesting.SeedInfo.seed([94F8C6D1C313A305:842729917784B529]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.index.TestBackwardsCompatibility.testAllVersionsTested(TestBackwardsCompatibility.java:633)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 

[jira] [Updated] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe updated SOLR-11993:
--
Fix Version/s: (was: 7.3)
   (was: master (8.0))
   6.6.3

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 6.6.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[JENKINS] Lucene-Solr-6.6-Windows (64bit/jdk-9.0.1) - Build # 69 - Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Windows/69/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

10 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.memory.TestFSTOrdPostingsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001\index-NIOFSDirectory-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001\index-NIOFSDirectory-001

C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001\index-NIOFSDirectory-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001\index-NIOFSDirectory-001
   
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\codecs\test\J0\temp\lucene.codecs.memory.TestFSTOrdPostingsFormat_3DC02E9A29E7B0D8-001

at __randomizedtesting.SeedInfo.seed([3DC02E9A29E7B0D8]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.lucene.index.TestDemoParallelLeafReader.testRandomMultipleSchemaGensSameField

Error Message:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\core\test\J1\temp\lucene.index.TestDemoParallelLeafReader_D481A90378A8823F-001\tempDir-001\segs\9fgbxl9m8mdzrxkh4x0zsi4nc_0:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\core\test\J1\temp\lucene.index.TestDemoParallelLeafReader_D481A90378A8823F-001\tempDir-001\segs\9fgbxl9m8mdzrxkh4x0zsi4nc_0
 

Stack Trace:
java.lang.RuntimeException: java.io.IOException: Could not remove the following 
files (in the order of attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\core\test\J1\temp\lucene.index.TestDemoParallelLeafReader_D481A90378A8823F-001\tempDir-001\segs\9fgbxl9m8mdzrxkh4x0zsi4nc_0:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.6-Windows\lucene\build\core\test\J1\temp\lucene.index.TestDemoParallelLeafReader_D481A90378A8823F-001\tempDir-001\segs\9fgbxl9m8mdzrxkh4x0zsi4nc_0

at 
__randomizedtesting.SeedInfo.seed([D481A90378A8823F:84D0A2C28F5ED326]:0)
at 
org.apache.lucene.index.TestDemoParallelLeafReader$ReindexingReader$ParallelLeafDirectoryReader$1.wrap(TestDemoParallelLeafReader.java:202)
at 
org.apache.lucene.index.FilterDirectoryReader$SubReaderWrapper.wrap(FilterDirectoryReader.java:56)
at 
org.apache.lucene.index.FilterDirectoryReader$SubReaderWrapper.access$000(FilterDirectoryReader.java:51)
at 
org.apache.lucene.index.FilterDirectoryReader.(FilterDirectoryReader.java:83)
at 

[jira] [Commented] (SOLR-10912) Adding automatic patch validation

2018-03-01 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-10912:
-

On what to do if there's no CHANGES.txt entry: The goal is to make sure the 
changelog update doesn't fall through the cracks and get forgotten.  If the -0 
accomplishes that, then that's great.

bq. Some issues require changes in both places.  Is there some issue you're 
trying to address besides release noting both projects?  I ask because Solr 
users really need to pay attention to Lucene CHANGES regardless.

I'm not trying to prevent one issue changing both sections of the codebase, 
just trying to make sure that if it happens, there's an explicit note in both 
changelogs.  Obviously a lot of LUCENE changes directly affect Solr even if 
they don't change Solr code, and for those, only updating the Lucene changelog 
is the right thing to do, and it's up to Solr users to read Lucene's changelog. 
 But if an issue on one part of the project actually makes changes to the code 
in the other, I think the documentation bar should be a little bit higher.

Additional idea:  Record a -1 if a SOLR issue *only* makes changes to Lucene 
code, or vice versa.  But when this happens, a changelog entry won't be enough 
to adjust to -0.


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, 
> SOLR-10912.sample-patch.patch, SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



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

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



[jira] [Comment Edited] (SOLR-5351) More Like This Handler uses only first field in mlt.fl when using stream.body

2018-03-01 Thread Tommaso Teofili (JIRA)

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

Tommaso Teofili edited comment on SOLR-5351 at 3/1/18 2:19 PM:
---

+1 thanks [~dweiss] , the patch looks good to me !


was (Author: teofili):
+1 thanks [~dweiss] , the patch looks good to me, thanks !

> More Like This Handler uses only first field in mlt.fl when using stream.body
> -
>
> Key: SOLR-5351
> URL: https://issues.apache.org/jira/browse/SOLR-5351
> Project: Solr
>  Issue Type: Bug
>  Components: MoreLikeThis
>Affects Versions: 4.4
> Environment: Linux,Windows
>Reporter: Zygmunt Wiercioch
>Assignee: Tommaso Teofili
>Priority: Minor
> Attachments: SOLR-5351.patch, SOLR-5351.patch
>
>
> The documentation at: http://wiki.apache.org/solr/MoreLikeThisHandler 
> indicates that one can use multiple fields for similarity in mlt.fl:
> http://localhost:8983/solr/mlt?stream.body=electronics%20memory=manu,cat=list=0
> In trying this, only one field is used. 
> Looking at the code, it only looks at the first field:
>  public DocListAndSet getMoreLikeThis( Reader reader, int start, int rows, 
> List filters, List terms, int flags ) throws 
> IOException
> {
>   // analyzing with the first field: previous (stupid) behavior
>   rawMLTQuery = mlt.like(reader, mlt.getFieldNames()[0]); 



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

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



[jira] [Commented] (SOLR-5351) More Like This Handler uses only first field in mlt.fl when using stream.body

2018-03-01 Thread Tommaso Teofili (JIRA)

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

Tommaso Teofili commented on SOLR-5351:
---

+1 thanks [~dweiss] , the patch looks good to me, thanks !

> More Like This Handler uses only first field in mlt.fl when using stream.body
> -
>
> Key: SOLR-5351
> URL: https://issues.apache.org/jira/browse/SOLR-5351
> Project: Solr
>  Issue Type: Bug
>  Components: MoreLikeThis
>Affects Versions: 4.4
> Environment: Linux,Windows
>Reporter: Zygmunt Wiercioch
>Assignee: Tommaso Teofili
>Priority: Minor
> Attachments: SOLR-5351.patch, SOLR-5351.patch
>
>
> The documentation at: http://wiki.apache.org/solr/MoreLikeThisHandler 
> indicates that one can use multiple fields for similarity in mlt.fl:
> http://localhost:8983/solr/mlt?stream.body=electronics%20memory=manu,cat=list=0
> In trying this, only one field is used. 
> Looking at the code, it only looks at the first field:
>  public DocListAndSet getMoreLikeThis( Reader reader, int start, int rows, 
> List filters, List terms, int flags ) throws 
> IOException
> {
>   // analyzing with the first field: previous (stupid) behavior
>   rawMLTQuery = mlt.like(reader, mlt.getFieldNames()[0]); 



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

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



[jira] [Comment Edited] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe edited comment on SOLR-11993 at 3/1/18 2:07 PM:
---

[~caomanhdat], is the attached patch all that needs to be done here (patch is 
against branch_6_6)?


was (Author: steve_rowe):
[~caomanhdat], is the attached patch all that needs to be done here?

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[jira] [Commented] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe commented on SOLR-11993:
---

[~caomanhdat], is the attached patch all that needs to be done here?

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[jira] [Updated] (SOLR-11993) LeaderInitiatedRecoveryThread does not retry on UnknownHostException

2018-03-01 Thread Steve Rowe (JIRA)

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

Steve Rowe updated SOLR-11993:
--
Attachment: SOLR-11993.patch

> LeaderInitiatedRecoveryThread does not retry on UnknownHostException
> 
>
> Key: SOLR-11993
> URL: https://issues.apache.org/jira/browse/SOLR-11993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.5, 7.2, 6.6.2
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11993.patch
>
>
> The LIR thread has a whitelist of exceptions on which it retries. It should 
> include UnknownHostException to avoid cases where a flaky DNS server (AWS 
> Route53!) can cause replicas to be stuck in "down" state until restarted.



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

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



[jira] [Updated] (SOLR-5351) More Like This Handler uses only first field in mlt.fl when using stream.body

2018-03-01 Thread Dawid Weiss (JIRA)

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

Dawid Weiss updated SOLR-5351:
--
Attachment: SOLR-5351.patch

> More Like This Handler uses only first field in mlt.fl when using stream.body
> -
>
> Key: SOLR-5351
> URL: https://issues.apache.org/jira/browse/SOLR-5351
> Project: Solr
>  Issue Type: Bug
>  Components: MoreLikeThis
>Affects Versions: 4.4
> Environment: Linux,Windows
>Reporter: Zygmunt Wiercioch
>Assignee: Tommaso Teofili
>Priority: Minor
> Attachments: SOLR-5351.patch, SOLR-5351.patch
>
>
> The documentation at: http://wiki.apache.org/solr/MoreLikeThisHandler 
> indicates that one can use multiple fields for similarity in mlt.fl:
> http://localhost:8983/solr/mlt?stream.body=electronics%20memory=manu,cat=list=0
> In trying this, only one field is used. 
> Looking at the code, it only looks at the first field:
>  public DocListAndSet getMoreLikeThis( Reader reader, int start, int rows, 
> List filters, List terms, int flags ) throws 
> IOException
> {
>   // analyzing with the first field: previous (stupid) behavior
>   rawMLTQuery = mlt.like(reader, mlt.getFieldNames()[0]); 



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

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



[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_144) - Build # 7200 - Still Unstable!

2018-03-01 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7200/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

14 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.analysis.core.TestRandomChains

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

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.core.TestRandomChains_578AF065CC7E8AFA-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\J1\temp\lucene.analysis.core.TestRandomChains_578AF065CC7E8AFA-001
 

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

at __randomizedtesting.SeedInfo.seed([578AF065CC7E8AFA]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
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:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.lucene50.TestLucene50StoredFieldsFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestLucene50StoredFieldsFormat_593AA69D187D08E4-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestLucene50StoredFieldsFormat_593AA69D187D08E4-001\justSoYouGetSomeChannelErrors-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestLucene50StoredFieldsFormat_593AA69D187D08E4-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestLucene50StoredFieldsFormat_593AA69D187D08E4-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestLucene50StoredFieldsFormat_593AA69D187D08E4-001\justSoYouGetSomeChannelErrors-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestLucene50StoredFieldsFormat_593AA69D187D08E4-001\justSoYouGetSomeChannelErrors-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.codecs.lucene50.TestLucene50StoredFieldsFormat_593AA69D187D08E4-001:
 java.nio.file.DirectoryNotEmptyException: 

[jira] [Comment Edited] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Minoru Osuka (JIRA)

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

Minoru Osuka edited comment on SOLR-11795 at 3/1/18 1:29 PM:
-

Hi [~koji] and [~thetaphi]

I apologize for the delay.
I attached the latest patch (SOLR-11795-10.patch) that gathered all changes 
into one.
- Changed configuration file format to XML.
- Included dev-tools.


Could you please test it on a test branch?


was (Author: minoru):
Hi [~koji] and [~thetaphi]

I apologize for the delay.
I attached the latest patch (SOLR-11795-10.patch) that gathered all changes 
into one.
- Changed configuration file format to XML.
- Included dev-tools.

Could you please test it on a test branch?

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-2.patch, 
> SOLR-11795-3.patch, SOLR-11795-4.patch, SOLR-11795-5.patch, 
> SOLR-11795-6.patch, SOLR-11795-7.patch, SOLR-11795-8.patch, 
> SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, SOLR-11795.patch, 
> solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

2018-03-01 Thread Minoru Osuka (JIRA)

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

Minoru Osuka commented on SOLR-11795:
-

Hi [~koji] and [~thetaphi]

I apologize for the delay.
I attached the latest patch (SOLR-11795-10.patch) that gathered all changes 
into one.
- Changed configuration file format to XML.
- Included dev-tools.

Could you please test it on a test branch?

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-2.patch, 
> SOLR-11795-3.patch, SOLR-11795-4.patch, SOLR-11795-5.patch, 
> SOLR-11795-6.patch, SOLR-11795-7.patch, SOLR-11795-8.patch, 
> SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, SOLR-11795.patch, 
> solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



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

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



  1   2   >