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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/23/
Java: 32bit/jdk1.8.0_162 -server -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([3CC737C903A7B564:C58AA4663FD2F8EE]: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:284)
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.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 
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 

[jira] [Commented] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12155:
-

Ok. Thanks, [~werder]. Lets' try.

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



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

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

[jira] [Updated] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12155:

Attachment: SOLR-12155.patch

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



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

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

[jira] [Reopened] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev reopened SOLR-12155:
-

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



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

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

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

[Policeman Jenkins Server]

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

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

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

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 892b4bb6b0dd6e16d31d9f54f0e978d6d78a6091

[repro] Repro line:  ant test  -Dtestcase=NodeAddedTriggerTest 
-Dtests.method=testRestoreState -Dtests.seed=2DFF4E1528A2A298 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=pt-PT 
-Dtests.timezone=Europe/Tallinn -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=MetricTriggerIntegrationTest 
-Dtests.method=testMetricTrigger -Dtests.seed=2DFF4E1528A2A298 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sk 
-Dtests.timezone=Asia/Shanghai -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TemplateUpdateProcessorTest 
-Dtests.method=testSimple -Dtests.seed=2DFF4E1528A2A298 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=mt-MT 
-Dtests.timezone=America/North_Dakota/Center -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestCloudSchemaless 
-Dtests.method=test -Dtests.seed=2DFF4E1528A2A298 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=fi-FI -Dtests.timezone=America/Belize 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestCloudSchemaless 
-Dtests.seed=2DFF4E1528A2A298 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=fi-FI -Dtests.timezone=America/Belize -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: 
3028f3e9ea337f9b8b0d021ecf3f2cb54217c566
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout 892b4bb6b0dd6e16d31d9f54f0e978d6d78a6091

[...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]   TemplateUpdateProcessorTest
[repro]   TestCloudSchemaless
[repro]   NodeAddedTriggerTest
[repro]   MetricTriggerIntegrationTest
[repro] ant compile-test

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 
-Dtests.class="*.TemplateUpdateProcessorTest|*.TestCloudSchemaless|*.NodeAddedTriggerTest|*.MetricTriggerIntegrationTest"
 -Dtests.showOutput=onerror  -Dtests.seed=2DFF4E1528A2A298 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=mt-MT 
-Dtests.timezone=America/North_Dakota/Center -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.schema.TestCloudSchemaless
[repro]   0/5 failed: 
org.apache.solr.update.processor.TemplateUpdateProcessorTest
[repro]   1/5 failed: org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest
[repro]   3/5 failed: 
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest
[repro] git checkout 3028f3e9ea337f9b8b0d021ecf3f2cb54217c566

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

[...truncated 5 lines...]

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

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

[Apache Jenkins Server]

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

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

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

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

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

[Apache Jenkins Server]

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

No tests ran.

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

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

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


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

SOLR-12028: Remove BadApple for 
CollectionsAPIDistributedZkTest.testCollectionReload()


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



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

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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12028:


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

SOLR-12028: Remove BadApple for 
CollectionsAPIDistributedZkTest.testCollectionReload()


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



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

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

[jira] [Commented] (SOLR-12131) Authorization plugin support for getting user's roles from the outside

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-12131:
---

I've gone through the patch. I'm wondering how exactly is this role information 
sent. Did you say that the role information is sent as part of the request 
itself? what are the security implications if you do so? 

> Authorization plugin support for getting user's roles from the outside
> --
>
> Key: SOLR-12131
> URL: https://issues.apache.org/jira/browse/SOLR-12131
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the {{RuleBasedAuthorizationPlugin}} relies on explicitly mapping 
> users to roles. However, when users are authenticated by an external Identity 
> service (e.g. JWT as implemented in SOLR-12121), that external service keeps 
> track of the user's roles, and will pass that as a "claim" in the token (JWT).
> In order for Solr to be able to Authorise requests based on those roles, the 
> Authorization plugin should be able to accept (verified) roles from the 
> request instead of explicit mapping.
> Suggested approach is to create a new interface {{VerifiedUserRoles}} and a 
> {{PrincipalWithUserRoles}} which implements the interface. The Authorization 
> plugin can then pull the roles from request. By piggy-backing on the 
> Principal, we have a seamless way to transfer extra external information, and 
> there is also a natural relationship:
> {code:java}
> User Authentication -> Role validation -> Creating a Principal{code}
> I plan to add the interface, the custom Principal class and restructure 
> {{RuleBasedAuthorizationPlugin}} in an abstract base class and two 
> implementations: {{RuleBasedAuthorizationPlugin}} (as today) and a new 
> {{ExternalRoleRuleBasedAuthorizationPlugin.}}



--
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-12200) ZkControllerTest failure. Leaking Overseer

[Lucene/Solr QA (JIRA)]

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

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

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


This message was automatically generated.



> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, SOLR-12200.patch, 
> patch-unit-solr_core.zip, tests-failures.txt, tests-failures.txt.gz, 
> zk.fail.txt.gz
>
>
> Failure seems suspiciously the same. 
>[junit4]   2> 499919 INFO  
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) 
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer 
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4]   2> 499920 INFO  
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4]   2> 499920 ERROR 
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
>  [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4]   2> java.lang.InterruptedException: null
>[junit4]   2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4]   2>at java.lang.Object.wait(Object.java:502) 
> ~[?:1.8.0_152]
>[junit4]   2>at 
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) 
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due 
> to leaking Overseer. 



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

-
To unsubscribe, 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1531 - Failure

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([B873F742D5FBF37D:8BC1DF86D84C29CA]:0)
at org.apache.lucene.store.RAMFile.newBuffer(RAMFile.java:78)
at org.apache.lucene.store.RAMFile.addBuffer(RAMFile.java:51)
at 
org.apache.lucene.store.RAMOutputStream.switchCurrentBuffer(RAMOutputStream.java:164)
at 
org.apache.lucene.store.RAMOutputStream.writeBytes(RAMOutputStream.java:150)
at 
org.apache.lucene.store.MockIndexOutputWrapper.writeBytes(MockIndexOutputWrapper.java:141)
at 
org.apache.lucene.codecs.lucene50.Lucene50PostingsWriter.finishTerm(Lucene50PostingsWriter.java:417)
at 
org.apache.lucene.codecs.PushPostingsWriterBase.writeTerm(PushPostingsWriterBase.java:176)
at 
org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter$TermsWriter.write(BlockTreeTermsWriter.java:865)
at 
org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter.write(BlockTreeTermsWriter.java:344)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsWriter.write(PerFieldPostingsFormat.java:141)
at 
org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:110)
at 
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:173)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:463)
at 
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:556)
at 
org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:416)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:517)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1774)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1466)
at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:185)
at 
org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit(TestDocTermOrds.java:171)
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)


FAILED:  org.apache.solr.uninverting.TestDocTermOrds.testNumericEncoded64

Error Message:
Captured an uncaught exception in thread: Thread[id=158876, name=Lucene Merge 
Thread #34, state=RUNNABLE, group=TGRP-TestDocTermOrds]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=158876, name=Lucene Merge Thread #34, 
state=RUNNABLE, group=TGRP-TestDocTermOrds]
at 
__randomizedtesting.SeedInfo.seed([B873F742D5FBF37D:9461C646A1138FC4]:0)
Caused by: org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.OutOfMemoryError: Java heap space
at __randomizedtesting.SeedInfo.seed([B873F742D5FBF37D]:0)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:704)
at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:684)
Caused by: java.lang.OutOfMemoryError: Java heap space
at org.apache.lucene.store.RAMFile.newBuffer(RAMFile.java:78)
at org.apache.lucene.store.RAMFile.addBuffer(RAMFile.java:51)
at 
org.apache.lucene.store.RAMOutputStream.switchCurrentBuffer(RAMOutputStream.java:164)
at 
org.apache.lucene.store.RAMOutputStream.writeBytes(RAMOutputStream.java:150)
at 
org.apache.lucene.store.MockIndexOutputWrapper.writeBytes(MockIndexOutputWrapper.java:141)
at 
org.apache.lucene.store.RateLimitedIndexOutput.writeBytes(RateLimitedIndexOutput.java:73)
at 

[jira] [Commented] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev commented on SOLR-12155:
---

Request object is not thread safe I guess. Try 
{code:java}
final SolrQueryRequest req = req("*:*");
final SolrIndexSearcher solrIndexSearcher = req.getSearcher();
.

initCallables.add(()-> UnInvertedField.getUnInvertedField(proto.field(), 
solrIndexSearcher));

.{code}

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



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

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

[jira] [Comment Edited] (SOLR-8291) NPE calling export handler when useFilterForSortedQuery=true

[Ron Ben-Yosef (JIRA)]

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

Ron Ben-Yosef edited comment on SOLR-8291 at 4/16/18 12:06 AM:
---

Hi,

I've run into the same issue, or at least what I think is the same issue (I'm 
on 7.2.1, and the call stack leading up to the exception looks somewhat 
different, but reading everything written here I'm fairly sure it's the same 
issue. If it's not - let me know and I can open a separate bug for it).

The scenario is similar - querying the /export handler with the 
"useFilterForSortedQuery" configuration option enabled.

Here's the call stack leading up to the exception:

o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at org.apache.lucene.util.BitSetIterator.(BitSetIterator.java:61)
at org.apache.solr.handler.ExportWriter.writeDocs(ExportWriter.java:243)
at org.apache.solr.handler.ExportWriter.lambda$null$1(ExportWriter.java:222)
at 
org.apache.solr.response.JSONWriter.writeIterator(JSONResponseWriter.java:523)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:180)
at org.apache.solr.response.JSONWriter$2.put(JSONResponseWriter.java:559)
at org.apache.solr.handler.ExportWriter.lambda$null$2(ExportWriter.java:222)
at org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547)
at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:198)
at org.apache.solr.response.JSONWriter$2.put(JSONResponseWriter.java:559)
at org.apache.solr.handler.ExportWriter.lambda$write$3(ExportWriter.java:220)
at org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547)
at org.apache.solr.handler.ExportWriter.write(ExportWriter.java:218)
at org.apache.solr.core.SolrCore$3.write(SolrCore.java:2627)
at 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:49)
at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:748)

 

Debugging the issue, it seems what's happening is that when there's more than 
one leaf (=segment?) then the per-leaf bitsets are being created only upto the 
highest leaf with matching documents, and if that's not the last leaf then 
you're going to have null bitsets for all the leaves higher than the highest 
one containing a matching document. This happens in SolrIndexSearcher.java in 
the function 

[jira] [Commented] (SOLR-8291) NPE calling export handler when useFilterForSortedQuery=true

[Ron Ben-Yosef (JIRA)]

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

Ron Ben-Yosef commented on SOLR-8291:
-

[^SOLR-8291.patch]

^The patch implements the first option - adding a null check for the bitsets in 
ExportWriter::writeDocs. Didn't want to do the second option for now, just 
being careful in case it has undesirable effects elsewhere that I might have 
missed (other collector types, other flows, etc.)^

 

^First time preparing and submitting a git patch, so I hope I'm doing it 
right...^ 

> NPE calling export handler when useFilterForSortedQuery=true
> 
>
> Key: SOLR-8291
> URL: https://issues.apache.org/jira/browse/SOLR-8291
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Ray
>Priority: Major
> Attachments: SOLR-8291.patch, solr.log
>
>
> *Updated*: The stacktrace below was created when the solrconfig.xml has the 
> following element:
> {code}
>  true
> {code}
> It was determined that useFilterForSortedQuery is incompatible with the 
> /export handler.
> See the comments near the end of the ticket for a potential work around if 
> this flag needs to be set.
> Get NPE during calling export handler, here is the stack trace:
>   at org.apache.lucene.util.BitSetIterator.(BitSetIterator.java:58)
>   at 
> org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:138)
>   at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:53)
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:727)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:459)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
>   at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
>   at 
> org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
>   at 
> org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
>   at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
>   at 
> org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:159)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>   at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>   at 
> org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
>   at 
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:489)
>   at 
> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:452)
>   at 
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2019)
>   at java.lang.Thread.run(Thread.java:745)
> It seems there are some FixedBitSet was set to null



--
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-8291) NPE calling export handler when useFilterForSortedQuery=true

[Ron Ben-Yosef (JIRA)]

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

Ron Ben-Yosef updated SOLR-8291:

Attachment: SOLR-8291.patch

> NPE calling export handler when useFilterForSortedQuery=true
> 
>
> Key: SOLR-8291
> URL: https://issues.apache.org/jira/browse/SOLR-8291
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Ray
>Priority: Major
> Attachments: SOLR-8291.patch, solr.log
>
>
> *Updated*: The stacktrace below was created when the solrconfig.xml has the 
> following element:
> {code}
>  true
> {code}
> It was determined that useFilterForSortedQuery is incompatible with the 
> /export handler.
> See the comments near the end of the ticket for a potential work around if 
> this flag needs to be set.
> Get NPE during calling export handler, here is the stack trace:
>   at org.apache.lucene.util.BitSetIterator.(BitSetIterator.java:58)
>   at 
> org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:138)
>   at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:53)
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:727)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:459)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
>   at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
>   at 
> org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
>   at 
> org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
>   at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
>   at 
> org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:159)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>   at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>   at 
> org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
>   at 
> org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:489)
>   at 
> org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:452)
>   at 
> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2019)
>   at java.lang.Thread.run(Thread.java:745)
> It seems there are some FixedBitSet was set to null



--
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-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8207:
-

Your third option seems best to me. You don't want to explicitly proxy. You 
want to ask your local node for information that it happens to need to get from 
other nodes, but that happens behind the scenes, based upon a node name.

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: nodes-tab.png
>
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
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: Next steps for Solr Admin UI - request for in-depth discussion

[Upayavira]

Jan,

The plus of the Angular upgrade path that I saw you mention elsewhere
was that you could have both old and new Angulars running in the same
app, and migrate slowly. That would work for a change of backend, using
the same styling.
It really depends on what your goal is: a refreshed UI or getting rid of
AngularJS.
My aim was to keep the UI the same as this gave a very clear way to
validate success. If you change the UI at the same time, identifying
success becomes harder.
Also, replacing the backend without changing the UI is quite possible
with limited graphic design skills. Modernising the UI would require a
different set of skills, and would probably involve us bringing in a UI
designer from somewhere to give us mocked-up components to start from.
So really, the question as to how best to do it will likely depend on
who is doing the work.
Upayavira

On Sun, 15 Apr 2018, at 6:13 PM, Jan Høydahl wrote:
> Just to be clear, Angular is now also built on components, transpiled
> and a rich toolset, including debugger, unit testing, end-to-end
> tests, CLI with scaffolding for adding new components/services etc.> 
> Building using components will also help prepare the new UI for a
> plugin architecture where Solr contribs/plug-ins add their own UI menu
> items and screens dynamically (dynamic loading vs build-time
> compiling).> 
> The old UI grows with more screens and features week by week so the
> burden of switching does not become smaller if we wait.> 
> Upayavira, moving from jQuery to AngularJS took the approach of
> building a clean parallel  code base, with the downside of years of
> maintaining two UIs. Do you see any better approach this time around?> 
> Jan
> 
> Sendt fra min iPhone
> 
> 15. apr. 2018 kl. 14:20 skrev Upayavira :
>> 
>> 
>> On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote:
>>> Hello,
>>>
>>> The relevant JIRA is SOLR-12196, but we felt this deserved a greater
>>> discussion.
>>>
>>> Basically, our Admin UI is currently using AngularJS (1.x) as its
>>> Javascript framework. That particular library has reached its
>>> evolutionary end long time ago and is about to stop being supported
>>> all together. The later versions of Angular carry the same name, but
>>> are _very_ _very_ different. So, despite the heroic efforts that got
>>> us here, we are facing this choice again. Also, as we were just
>>> trying to migrate the UI and not rethink it, the underlying
>>> design/file layout/plugin architecture is also quite problematic.
>>>
>>> The question is what is the right thing to do next. There are
>>> basically four options:
>>> 1) Migrate to the latest Angular in an incremental fashion (as per
>>>JIRA's original proposal)
>>> 2) Jump to a different library (such as React or Vue) which got a
>>>much stronger momentum and ecosystem these days, but sort of keep
>>>current architecture (UI feel/approach)
>>> 3) Go blue-sky with new library and actually put some deep thought
>>>into modern UI leveraging Solr's current features (Management
>>>API, JSON, etc). Also, by picking React (for example) we get
>>>access to the ecosystem of modern tools, extensions and even
>>>potentially mobile apps.
>>> 4) Drop our own UI and adopt somebody else's (I don't have any good
>>>suggestions here though)?
>>>
>>> Normally, option 1 would be the sane one. The challenge is two fold
>>> though:
>>> a) Even option 1 is a lot of work due the Angular team's radical
>>>change of direction. Enough that it will lock us out from any
>>>other option for at least another 3-4 years.
>>> b) We are all server-side developers. So, even the simple Javascript
>>>things are hard for us, never mind the CSS part. So, this makes
>>>the cost of starting with any new approach dis-proportionally
>>>hard. Once going, it is a bit easier, because the advanced
>>>concepts are similar to other languages.
>>>
>>> All of these, combined with all the open JIRAs on Admin issues
>>> - to me
>>> - make option 3 less crazy than usual.
>>>
>>> What do others think? Is there discontent with the current state of
>>> Admin UI (apart from the implementation choice)? Are there secret
>>> web designers here, willing to get us over a bump of migration? Is
>>> there a company out there, willing to sponsor relevant skills to let
>>> us leapfrog the incremental upgrade (similar to how we got the
>>> Reference Guide).>> 
>> As you know, I'm responsible for the current UI. The aims in building
>> this version of the UI were to keep the visuals entirely the same,
>> whilst reducing the size and complexity of the underlying JavaScript
>> (we reduced it by about 50% in terms of LoC). The bulk of the work in
>> its implementation was in terms of understanding the intent of the
>> existing code. Reproducing it in new code was a smaller task by
>> comparison. I hope this will pay off in any future rewrite.>> 
>> At the time, the JavaScript landscape was changing fast. It 

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

[Policeman Jenkins Server]

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

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

Error Message:
action did not start

Stack Trace:
java.lang.AssertionError: action did not start
at 
__randomizedtesting.SeedInfo.seed([4164E7EDC1C70AF4:88D1A543C8A0CC01]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue(TestTriggerIntegration.java:641)
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)




Build Log:
[...truncated 1855 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J0-20180415_213117_5005787694559258165396.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   

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

[Apache Jenkins Server]

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

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

[repro] Revision: 892b4bb6b0dd6e16d31d9f54f0e978d6d78a6091

[repro] Repro line:  ant test  -Dtestcase=TestCollectionsAPIViaSolrCloudCluster 
-Dtests.method=testCollectionCreateSearchDelete -Dtests.seed=CE06C185C04F8F23 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=lv-LV -Dtests.timezone=US/Eastern -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=CollectionsAPIDistributedZkTest 
-Dtests.method=testCollectionsAPI -Dtests.seed=CE06C185C04F8F23 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=ar-MA -Dtests.timezone=Pacific/Tahiti -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=LegacyCloudClusterPropTest 
-Dtests.method=testCreateCollectionSwitchLegacyCloud 
-Dtests.seed=CE06C185C04F8F23 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=zh-SG -Dtests.timezone=America/Tortola 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestPullReplica 
-Dtests.method=testKillLeader -Dtests.seed=CE06C185C04F8F23 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=id 
-Dtests.timezone=America/Goose_Bay -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestTlogReplica 
-Dtests.method=testRecovery -Dtests.seed=CE06C185C04F8F23 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=en-NZ 
-Dtests.timezone=Australia/Yancowinna -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestLargeCluster 
-Dtests.method=testBasic -Dtests.seed=CE06C185C04F8F23 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=fr-CH 
-Dtests.timezone=Atlantic/Canary -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
dad2d1076db632535c33fa118eb851ad7d0e2537
[repro] git fetch
[repro] git checkout 892b4bb6b0dd6e16d31d9f54f0e978d6d78a6091

[...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]   LegacyCloudClusterPropTest
[repro]   TestLargeCluster
[repro]   TestPullReplica
[repro]   CollectionsAPIDistributedZkTest
[repro]   TestCollectionsAPIViaSolrCloudCluster
[repro]   TestTlogReplica
[repro] ant compile-test

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=30 
-Dtests.class="*.LegacyCloudClusterPropTest|*.TestLargeCluster|*.TestPullReplica|*.CollectionsAPIDistributedZkTest|*.TestCollectionsAPIViaSolrCloudCluster|*.TestTlogReplica"
 -Dtests.showOutput=onerror  -Dtests.seed=CE06C185C04F8F23 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=zh-SG 
-Dtests.timezone=America/Tortola -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.LegacyCloudClusterPropTest
[repro]   0/5 failed: org.apache.solr.cloud.TestPullReplica
[repro]   0/5 failed: 
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest
[repro]   0/5 failed: 
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster
[repro]   0/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster
[repro]   1/5 failed: org.apache.solr.cloud.TestTlogReplica
[repro] git checkout dad2d1076db632535c33fa118eb851ad7d0e2537

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

[...truncated 6 lines...]

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

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

[Apache Jenkins Server]

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

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/200/consoleText

[repro] Revision: 892b4bb6b0dd6e16d31d9f54f0e978d6d78a6091

[repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9
[repro] Repro line:  ant test  -Dtestcase=SystemLogListenerTest 
-Dtests.method=test -Dtests.seed=BB1601802A0029 -Dtests.multiplier=2 
-Dtests.locale=ar-AE -Dtests.timezone=America/Glace_Bay -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: 
dad2d1076db632535c33fa118eb851ad7d0e2537
[repro] git fetch
[repro] git checkout 892b4bb6b0dd6e16d31d9f54f0e978d6d78a6091

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

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.SystemLogListenerTest" -Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=BB1601802A0029 -Dtests.multiplier=2 -Dtests.locale=ar-AE 
-Dtests.timezone=America/Glace_Bay -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.autoscaling.SystemLogListenerTest
[repro] git checkout dad2d1076db632535c33fa118eb851ad7d0e2537

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

[...truncated 5 lines...]

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest

Error Message:
7 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest: 1) 
Thread[id=18896, name=zkConnectionManagerCallback-2344-thread-1, state=WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.4/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@9.0.4/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9.0.4/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=19487, name=zkCallback-2343-thread-7, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.4/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9.0.4/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1091)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)3) 
Thread[id=19436, name=zkCallback-2343-thread-5, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.4/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9.0.4/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9.0.4/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1091)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)4) 
Thread[id=18894, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[FD41D078D8141FB9]-SendThread(127.0.0.1:38645),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]  
   at java.base@9.0.4/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.ClientCnxnSocketNIO.cleanup(ClientCnxnSocketNIO.java:230)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1249)   
  at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1173)5) 
Thread[id=18895, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[FD41D078D8141FB9]-EventThread,
 state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
 at java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9.0.4/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@9.0.4/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9.0.4/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)6) 
Thread[id=18893, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@9.0.4/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at 

[jira] [Commented] (SOLR-12224) there is no API to read collection properties

[Hendrik Haddorp (JIRA)]

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

Hendrik Haddorp commented on SOLR-12224:


An option could also be to have an option to control how much detail 
CLUSTERSTATUS is returning. But getting the information via COLLECTIONPROP is 
also fine to me.

> there is no API to read collection properties
> -
>
> Key: SOLR-12224
> URL: https://issues.apache.org/jira/browse/SOLR-12224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3
>Reporter: Hendrik Haddorp
>Priority: Major
>
> Solr 7.3 added the COLLECTIONPROP API call 
> (https://lucene.apache.org/solr/guide/7_3/collections-api.html#collectionprop)
>  that allows to set arbitrary properties on a collection. There is however no 
> API call that returns the data. The only option is to manually read out the 
> collectionprops.json file in ZK below the collection.
> Options could be that the COLLECTIONPROP command has an option to retrieve 
> properties, have a special command to list the properties and/or to have the 
> properties listed in the clusterstatus output for a collection.
> Would be great if SolrJ would also be supported.



--
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-12224) there is no API to read collection properties

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12224:
-

I'm not strongly opposed to having the info in CLUSTERSTATUS.  It just seems 
like the wrong place to put it, since the info is only applicable to the 
collections that have the properties, not the whole cluster.

> there is no API to read collection properties
> -
>
> Key: SOLR-12224
> URL: https://issues.apache.org/jira/browse/SOLR-12224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3
>Reporter: Hendrik Haddorp
>Priority: Major
>
> Solr 7.3 added the COLLECTIONPROP API call 
> (https://lucene.apache.org/solr/guide/7_3/collections-api.html#collectionprop)
>  that allows to set arbitrary properties on a collection. There is however no 
> API call that returns the data. The only option is to manually read out the 
> collectionprops.json file in ZK below the collection.
> Options could be that the COLLECTIONPROP command has an option to retrieve 
> properties, have a special command to list the properties and/or to have the 
> properties listed in the clusterstatus output for a collection.
> Would be great if SolrJ would also be supported.



--
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-12224) there is no API to read collection properties

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12224:
-

If collection properties are part of CLUSTERSTATUS, the response could 
potentially be quite large.  If there are five hundred collections, each with a 
handful of properties, that's a lot of information.  Somebody who's after a 
quick cluster-wide status response probably isn't interested in all of that.  
Gathering it will also increase the response time.

I think it is best to allow the existing COLLECTIONPROP action to return the 
properties when the request is missing parameters, or create a new action 
specifically for listing them.

> there is no API to read collection properties
> -
>
> Key: SOLR-12224
> URL: https://issues.apache.org/jira/browse/SOLR-12224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3
>Reporter: Hendrik Haddorp
>Priority: Major
>
> Solr 7.3 added the COLLECTIONPROP API call 
> (https://lucene.apache.org/solr/guide/7_3/collections-api.html#collectionprop)
>  that allows to set arbitrary properties on a collection. There is however no 
> API call that returns the data. The only option is to manually read out the 
> collectionprops.json file in ZK below the collection.
> Options could be that the COLLECTIONPROP command has an option to retrieve 
> properties, have a special command to list the properties and/or to have the 
> properties listed in the clusterstatus output for a collection.
> Would be great if SolrJ would also be supported.



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

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

[jira] [Commented] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12155:
-

I've checked my inbox, this test fails on Policeman Jenkins with the same 
reason:
{quote}
   [junit4]   2> 2243589 INFO  (coreCloseExecutor-5165-thread-1) [
x:collection1] o.a.s.m.r.SolrJmxReporter Closing reporter 
[org.apache.solr.metrics.reporters.SolrJmxReporter@35c0872f: rootName = null, 
domain = solr.core.collection1, service url = null, agent id = null] for 
registry solr.core.collection1 / com.codahale.metrics.MetricRegistry@307026
   [junit4]   2> 2255707 ERROR (coreCloseExecutor-5165-thread-1) [
x:collection1] o.a.s.c.CachingDirectoryFactory Timeout waiting for all 
directory ref counts to be released - gave up waiting on 

[jira] [Commented] (LUCENE-8253) ForceMergeDeletes does not merge soft-deleted segments

[Nhat Nguyen (JIRA)]

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

Nhat Nguyen commented on LUCENE-8253:
-

FYI [~simonw]

> ForceMergeDeletes does not merge soft-deleted segments
> --
>
> Key: LUCENE-8253
> URL: https://issues.apache.org/jira/browse/LUCENE-8253
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.4, master (8.0)
>Reporter: Nhat Nguyen
>Priority: Major
> Attachments: test-merge.patch
>
>
> IndexWriter#forceMergeDeletes should merge segments having soft-deleted 
> documents as hard-deleted documents if we configured "softDeletesField" in an 
> IndexWriterConfig.
> Attached is a failed test.



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

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

[jira] [Created] (LUCENE-8253) ForceMergeDeletes does not merge soft-deleted segments

[Nhat Nguyen (JIRA)]

Nhat Nguyen created LUCENE-8253:
---

 Summary: ForceMergeDeletes does not merge soft-deleted segments
 Key: LUCENE-8253
 URL: https://issues.apache.org/jira/browse/LUCENE-8253
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 7.4, master (8.0)
Reporter: Nhat Nguyen
 Attachments: test-merge.patch

IndexWriter#forceMergeDeletes should merge segments having soft-deleted 
documents as hard-deleted documents if we configured "softDeletesField" in an 
IndexWriterConfig.

Attached is a failed test.



--
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-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-12155 at 4/15/18 7:47 PM:
--

https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21832/ 
[^21832-consoleText.txt.zip]



was (Author: mkhludnev):
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21832/


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



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

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

[jira] [Updated] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12155:

Attachment: 21832-consoleText.txt.zip

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



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

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

[jira] [Commented] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12155:
-

https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21832/


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



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

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

[jira] [Comment Edited] (SOLR-8207) Modernise cloud tab on Admin UI

[JIRA]

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

Jan Høydahl edited comment on SOLR-8207 at 4/15/18 6:50 PM:


For the new "Nodes" view, I am whipping up a patch and currently draw the whole 
table from the {{CLUSTERSTATUS}} info. But when trying to pull system/metrics 
info from other nodes we of course bump into CORS issues. There are two ways to 
work around this:
 * Add CORS support to Solr's Jetty, automatically allowing all host names in a 
cluster
 * Add some {{/api/proxy}} endpoint that will proxy requests from the UI to 
other nodes. Example:
{code:java}
/api/proxy?node=192.168.0.3:8983_solr=/api/node/system=foo{code}

I think the proxy approach is preferable since it will then also work if you 
only have access to one Solr node in a cluster, or you access Admin UI through 
ssh forwarding, where real host/IPs don't resolve from the client network. 
There are challenges with the proxy approach as well, as it needs to strictly 
allow only requests to whitelisted nodes that exist in ZK. It also needs to 
handle authentication, simplest is to always use PKI when talking to other 
nodes. Authorization must perhaps validate its permission rules relative to the 
resolved endpoint in addition to the /proxy/ one so this does not become a 
loophole to allow any action once authenticated. And finally, the handler 
should have config to lock down proxying to certain methods (only GET by 
default) and to certain endpoints.

*EDIT:* A third option is to add a new parameter {{}} to each API where 
the Admin UI needs info for other nodes than the local. E.g. 
{{/api/node/system?node=192.168.0.3:8983_solr}}


was (Author: janhoy):
For the new "Nodes" view, I am whipping up a patch and currently draw the whole 
table from the {{CLUSTERSTATUS}} info. But when trying to pull system/metrics 
info from other nodes we of course bump into CORS issues. There are two ways to 
work around this:
 * Add CORS support to Solr's Jetty, automatically allowing all host names in a 
cluster
 * Add some {{/api/proxy}} endpoint that will proxy requests from the UI to 
other nodes. Example:
{code:java}
/api/proxy?node=192.168.0.3:8983_solr=/api/node/system=foo{code}

I think the proxy approach is preferable since it will then also work if you 
only have access to one Solr node in a cluster, or you access Admin UI through 
ssh forwarding, where real host/IPs don't resolve from the client network. 
There are challenges with the proxy approach as well, as it needs to strictly 
allow only requests to whitelisted nodes that exist in ZK. It also needs to 
handle authentication, simplest is to always use PKI when talking to other 
nodes. Authorization must perhaps validate its permission rules relative to the 
resolved endpoint in addition to the /proxy/ one so this does not become a 
loophole to allow any action once authenticated. And finally, the handler 
should have config to lock down proxying to certain methods (only GET by 
default) and to certain endpoints.

*EDIT:* A third option is to add a new parameter {{ }}to each API where 
the Admin UI needs info for other nodes than the local. E.g. 
{{/api/node/system?node=192.168.0.3:8983_solr}}

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: nodes-tab.png
>
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we 

[jira] [Comment Edited] (SOLR-8207) Modernise cloud tab on Admin UI

[JIRA]

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

Jan Høydahl edited comment on SOLR-8207 at 4/15/18 6:49 PM:


For the new "Nodes" view, I am whipping up a patch and currently draw the whole 
table from the {{CLUSTERSTATUS}} info. But when trying to pull system/metrics 
info from other nodes we of course bump into CORS issues. There are two ways to 
work around this:
 * Add CORS support to Solr's Jetty, automatically allowing all host names in a 
cluster
 * Add some {{/api/proxy}} endpoint that will proxy requests from the UI to 
other nodes. Example:
{code:java}
/api/proxy?node=192.168.0.3:8983_solr=/api/node/system=foo{code}

I think the proxy approach is preferable since it will then also work if you 
only have access to one Solr node in a cluster, or you access Admin UI through 
ssh forwarding, where real host/IPs don't resolve from the client network. 
There are challenges with the proxy approach as well, as it needs to strictly 
allow only requests to whitelisted nodes that exist in ZK. It also needs to 
handle authentication, simplest is to always use PKI when talking to other 
nodes. Authorization must perhaps validate its permission rules relative to the 
resolved endpoint in addition to the /proxy/ one so this does not become a 
loophole to allow any action once authenticated. And finally, the handler 
should have config to lock down proxying to certain methods (only GET by 
default) and to certain endpoints.

*EDIT:* A third option is to add a new parameter {{ }}to each API where 
the Admin UI needs info for other nodes than the local. E.g. 
{{/api/node/system?node=192.168.0.3:8983_solr}}


was (Author: janhoy):
For the new "Nodes" view, I am whipping up a patch and currently draw the whole 
table from the {{CLUSTERSTATUS}} info. But when trying to pull system/metrics 
info from other nodes we of course bump into CORS issues. There are two ways to 
work around this:
 * Add CORS support to Solr's Jetty, automatically allowing all host names in a 
cluster
 * Add some {{/api/proxy}} endpoint that will proxy requests from the UI to 
other nodes. Example:
{code:java}
/api/proxy?node=192.168.0.3:8983_solr=/api/node/system=foo{code}

I think the proxy approach is preferable since it will then also work if you 
only have access to one Solr node in a cluster, or you access Admin UI through 
ssh forwarding, where real host/IPs don't resolve from the client network. 
There are challenges with the proxy approach as well, as it needs to strictly 
allow only requests to whitelisted nodes that exist in ZK. It also needs to 
handle authentication, simplest is to always use PKI when talking to other 
nodes. Authorization must perhaps validate its permission rules relative to the 
resolved endpoint in addition to the /proxy/ one so this does not become a 
loophole to allow any action once authenticated. And finally, the handler 
should have config to lock down proxying to certain methods (only GET by 
default) and to certain endpoints.

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: nodes-tab.png
>
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 

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

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest.testMetricTrigger

Error Message:
The trigger did not fire at all

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


FAILED:  org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testRestoreState

Error Message:
Did not expect the processor to fire on first run! event={   
"id":"15d908e1e772bcTylhcuf47e6ok3s3hutdj6vdy",   
"source":"node_added_trigger",   "eventTime":6149606683931324,   
"eventType":"NODEADDED",   

Re: Next steps for Solr Admin UI - request for in-depth discussion

[Shawn Heisey]

On 4/15/2018 11:13 AM, Jan Høydahl wrote:
Upayavira, moving from jQuery to AngularJS took the approach of 
building a clean parallel  code base, with the downside of years of 
maintaining two UIs. Do you see any better approach this time around?


I'm onboard with writing a whole new UI in a more modern framework.  I 
would love to help, but I feel that I'm not well qualified, because my 
understanding of Javascript and CSS isn't as complete as I think it 
needs to be.  I'm not completely useless in those fields, but it takes 
me longer to figure out how to do things.


I think we should do a similar switchover -- build a new UI, make it 
optional at first.  We could wait for 8.0 to make it primary, or if we 
feel it's ready, make it primary in a later 7.x release.  Then we can 
remove the old UI in the next major version after the default changes.  
As soon as the new UI is made primary, the old UI should have a note on 
every page saying that it is no longer maintained and may not work 
properly.  I don't think we should ignore bug reports on the old UI, but 
they won't need a high priority.


As part of a new UI, I think that we should be careful to duplicate and 
extend current *functionality*, but that we should not restrict 
ourselves to making it look/feel exactly like the current UI.  If a 
redesign would work better, especially on mobile, then we should do that.


The current UI does work a lot better on mobile devices than the 
previous UI.  I avoided using my smartphone for even information 
gathering because it was terrible.  I don't have a tablet, but I think 
that administration with tablets is becoming very common. My smartphone 
is in the "phablet" category -- large screen with higher than HD resolution.


Thanks,
Shawn

[jira] [Updated] (SOLR-12200) ZkControllerTest failure. Leaking Overseer

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12200:

Attachment: SOLR-12200.patch

> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, SOLR-12200.patch, 
> patch-unit-solr_core.zip, tests-failures.txt, tests-failures.txt.gz, 
> zk.fail.txt.gz
>
>
> Failure seems suspiciously the same. 
>[junit4]   2> 499919 INFO  
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) 
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer 
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4]   2> 499920 INFO  
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4]   2> 499920 ERROR 
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
>  [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4]   2> java.lang.InterruptedException: null
>[junit4]   2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4]   2>at java.lang.Object.wait(Object.java:502) 
> ~[?:1.8.0_152]
>[junit4]   2>at 
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) 
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due 
> to leaking Overseer. 



--
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: Next steps for Solr Admin UI - request for in-depth discussion

[Jan Høydahl]

Just to be clear, Angular is now also built on components, transpiled and a 
rich toolset, including debugger, unit testing, end-to-end tests, CLI with 
scaffolding for adding new components/services etc. 

Building using components will also help prepare the new UI for a plugin 
architecture where Solr contribs/plug-ins add their own UI menu items and 
screens dynamically (dynamic loading vs build-time compiling).

The old UI grows with more screens and features week by week so the burden of 
switching does not become smaller if we wait.

Upayavira, moving from jQuery to AngularJS took the approach of building a 
clean parallel  code base, with the downside of years of maintaining two UIs. 
Do you see any better approach this time around?

Jan

Sendt fra min iPhone

> 15. apr. 2018 kl. 14:20 skrev Upayavira :
> 
> 
> 
>> On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote:
>> Hello,
>> 
>> The relevant JIRA is SOLR-12196, but we felt this deserved a greater 
>> discussion.
>> 
>> Basically, our Admin UI is currently using AngularJS (1.x) as its
>> Javascript framework. That particular library has reached its
>> evolutionary end long time ago and is about to stop being supported
>> all together. The later versions of Angular carry the same name, but
>> are _very_ _very_ different. So, despite the heroic efforts that got
>> us here, we are facing this choice again. Also, as we were just trying
>> to migrate the UI and not rethink it, the underlying design/file
>> layout/plugin architecture is also quite problematic.
>> 
>> The question is what is the right thing to do next. There are
>> basically four options:
>> 1) Migrate to the latest Angular in an incremental fashion (as per
>> JIRA's original proposal)
>> 2) Jump to a different library (such as React or Vue) which got a much
>> stronger momentum and ecosystem these days, but sort of keep current
>> architecture (UI feel/approach)
>> 3) Go blue-sky with new library and actually put some deep thought
>> into modern UI leveraging Solr's current features (Management API,
>> JSON, etc). Also, by picking React (for example) we get access to the
>> ecosystem of modern tools, extensions and even potentially mobile
>> apps.
>> 4) Drop our own UI and adopt somebody else's (I don't have any good
>> suggestions here though)?
>> 
>> Normally, option 1 would be the sane one. The challenge is two fold though:
>> a) Even option 1 is a lot of work due the Angular team's radical
>> change of direction. Enough that it will lock us out from any other
>> option for at least another 3-4 years.
>> b) We are all server-side developers. So, even the simple Javascript
>> things are hard for us, never mind the CSS part. So, this makes the
>> cost of starting with any new approach dis-proportionally hard. Once
>> going, it is a bit easier, because the advanced concepts are similar
>> to other languages.
>> 
>> All of these, combined with all the open JIRAs on Admin issues - to me
>> - make option 3 less crazy than usual.
>> 
>> What do others think? Is there discontent with the current state of
>> Admin UI (apart from the implementation choice)? Are there secret web
>> designers here, willing to get us over a bump of migration? Is there a
>> company out there, willing to sponsor relevant skills to let us
>> leapfrog the incremental upgrade (similar to how we got the Reference
>> Guide).
> 
> As you know, I'm responsible for the current UI. The aims in building this 
> version of the UI were to keep the visuals entirely the same, whilst reducing 
> the size and complexity of the underlying JavaScript (we reduced it by about 
> 50% in terms of LoC). The bulk of the work in its implementation was in terms 
> of understanding the intent of the existing code. Reproducing it in new code 
> was a smaller task by comparison. I hope this will pay off in any future 
> rewrite.
> 
> At the time, the JavaScript landscape was changing fast. It was clear that 
> anything we produced would only be valid for a number of years. It seems we 
> have now reached that limit.
> 
> I have recently taught myself basic ReactJS. It is clearly a powerful beast. 
> The two major distinguishing factors from the current UI are its 
> componentised nature (which means you don't build pages, you build re-usable 
> components) and that it uses a transpiled language. 
> 
> To rebuild the current UI in React, we would need to decompose the HTML pages 
> into components, and migrate behaviour into those components.
> 
> Using a transpiled language (and all the tools that support that, e.g. 
> webpack) would give us a more compact, and modern, UI.
> 
> However, the HTML is growing old. It isn't properly responsive, and it 
> doesn't use idioms that people have come to expect from a UI (e.g. no 
> hamburgers).
> 
> In theory, I would support a rewrite of the visuals - it would make Solr seem 
> more modern. However, I do not underestimate the amount of work involved.
> 
> Upayavira
> 
> 

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

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, SolrIndexSearcher, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1040)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:864)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1051)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:647)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:352)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:730)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:955)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:864)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1051)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:647)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:192)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.search.SolrIndexSearcher  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.search.SolrIndexSearcher.(SolrIndexSearcher.java:325)  at 
org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2047)  at 
org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2220)  at 
org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1957)  at 
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:719)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:93)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:68)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor.java:1924)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1900)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:160)
  at org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:281) 
 at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:188)  at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2508)  at 
org.apache.solr.servlet.DirectSolrConnection.request(DirectSolrConnection.java:125)
  at org.apache.solr.util.TestHarness.update(TestHarness.java:284)  at 
org.apache.solr.util.BaseTestHarness.checkUpdateStatus(BaseTestHarness.java:281)
  at 
org.apache.solr.util.BaseTestHarness.validateUpdate(BaseTestHarness.java:251)  
at org.apache.solr.SolrTestCaseJ4.checkUpdateU(SolrTestCaseJ4.java:863)  at 
org.apache.solr.SolrTestCaseJ4.assertU(SolrTestCaseJ4.java:842)  at 
org.apache.solr.SolrTestCaseJ4.assertU(SolrTestCaseJ4.java:836)  at 
org.apache.solr.request.TestUnInvertedFieldException.createIndex(TestUnInvertedFieldException.java:73)
  at 
org.apache.solr.request.TestUnInvertedFieldException.setUp(TestUnInvertedFieldException.java:55)
  at 

[jira] [Commented] (SOLR-12200) ZkControllerTest failure. Leaking Overseer

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12200:
-

ok. I've got endless recursion locally.

{quote}
  [beaster] at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:138)
  [beaster] at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
  [beaster] at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)
{quote}

Stripping one line from the patch...   

> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, patch-unit-solr_core.zip, 
> tests-failures.txt, tests-failures.txt.gz, zk.fail.txt.gz
>
>
> Failure seems suspiciously the same. 
>[junit4]   2> 499919 INFO  
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) 
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer 
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4]   2> 499920 INFO  
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4]   2> 499920 ERROR 
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
>  [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4]   2> java.lang.InterruptedException: null
>[junit4]   2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4]   2>at java.lang.Object.wait(Object.java:502) 
> ~[?:1.8.0_152]
>[junit4]   2>at 
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) 
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due 
> to leaking Overseer. 



--
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-8998) JSON Facet API child roll-ups

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8998:


[~ysee...@gmail.com], do you think we need this algorithm in json.facet at all? 

> JSON Facet API child roll-ups
> -
>
> Key: SOLR-8998
> URL: https://issues.apache.org/jira/browse/SOLR-8998
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Reporter: Yonik Seeley
>Priority: Major
> Attachments: SOLR_8998.patch, SOLR_8998.patch, SOLR_8998.patch
>
>
> The JSON Facet API currently has the ability to map between parents and 
> children ( see http://yonik.com/solr-nested-objects/ )
> This issue is about adding a true rollup ability where parents would take on 
> derived values from their children.  The most important part (and the most 
> difficult part) will be the external API.



--
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-12200) ZkControllerTest failure. Leaking Overseer

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
56s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m 32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m 32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 93m  3s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}100m  8s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.api.collections.TestCollectionAPI |
|   | solr.cloud.RollingRestartTest |
|   | solr.cloud.OverseerRolesTest |
|   | solr.cloud.autoscaling.sim.TestLargeCluster |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12200 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12919074/SOLR-12200.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / dad2d10 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_152 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/56/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/56/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/56/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, patch-unit-solr_core.zip, 
> tests-failures.txt, tests-failures.txt.gz, zk.fail.txt.gz
>
>
> Failure seems suspiciously the same. 
>[junit4]   2> 499919 INFO  
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) 
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer 
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4]   2> 499920 INFO  
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4]   2> 499920 ERROR 
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
>  [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4]   2> java.lang.InterruptedException: null
>[junit4]   2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4]   2>at java.lang.Object.wait(Object.java:502) 
> ~[?:1.8.0_152]
>[junit4]   2>at 
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) 
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due 
> to leaking Overseer. 



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

[jira] [Commented] (SOLR-12200) ZkControllerTest failure. Leaking Overseer

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-12200:
-

the patch validation yields rather interesting failures 
[^patch-unit-solr_core.zip]

{quote}

[junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/temp/junit4-J0-20180414_200441_6807428998912001709385.syserr
 [junit4] >>> JVM J0 emitted unexpected output (verbatim)  [junit4] WARN: 
Unhandled exception in event serialization. -> java.lang.StackOverflowError 
[junit4] at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:691)

...

[junit4] at 
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:835)
 [junit4] at org.apache.solr.cloud.LeaderEle [junit4] 
ctor.runIamLeaderProcess(LeaderElector.java:170) [junit4] at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135) 
[junit4] at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307) 
[junit4] at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393) 
[junit4] at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:138)

{quote}

I hardly believe the patch might cause it. 

 

> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, patch-unit-solr_core.zip, 
> tests-failures.txt, tests-failures.txt.gz, zk.fail.txt.gz
>
>
> Failure seems suspiciously the same. 
>[junit4]   2> 499919 INFO  
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) 
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer 
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4]   2> 499920 INFO  
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4]   2> 499920 ERROR 
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
>  [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4]   2> java.lang.InterruptedException: null
>[junit4]   2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4]   2>at java.lang.Object.wait(Object.java:502) 
> ~[?:1.8.0_152]
>[junit4]   2>at 
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) 
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due 
> to leaking Overseer. 



--
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-12200) ZkControllerTest failure. Leaking Overseer

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-12200:

Attachment: patch-unit-solr_core.zip

> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, patch-unit-solr_core.zip, 
> tests-failures.txt, tests-failures.txt.gz, zk.fail.txt.gz
>
>
> Failure seems suspiciously the same. 
>[junit4]   2> 499919 INFO  
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) 
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer 
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4]   2> 499920 INFO  
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4]   2> 499920 ERROR 
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
>  [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4]   2> java.lang.InterruptedException: null
>[junit4]   2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4]   2>at java.lang.Object.wait(Object.java:502) 
> ~[?:1.8.0_152]
>[junit4]   2>at 
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) 
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due 
> to leaking Overseer. 



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

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

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

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud

Error Message:
Could not find collection : legacyFalse

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : legacyFalse
at 
__randomizedtesting.SeedInfo.seed([CE06C185C04F8F23:1F01330064400411]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:256)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.checkMandatoryProps(LegacyCloudClusterPropTest.java:154)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:91)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:71)
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 

[jira] [Updated] (SOLR-11840) Inconsistencies in the Usage Messages of bin/solr.cmd

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-11840:
---
Attachment: SOLR-11840.patch

> Inconsistencies in the Usage Messages of bin/solr.cmd
> -
>
> Key: SOLR-11840
> URL: https://issues.apache.org/jira/browse/SOLR-11840
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Jakob Furrer
>Priority: Major
>  Labels: documentation, easyfix
> Fix For: 7.2
>
> Attachments: SOLR-11840.patch, SOLR-11840.patch, solr.cmd.txt, 
> solr.txt, solr_start_help_Syntaxfehler.png
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I noticed a number of errors/problems/peculiarities in the Usage Messages 
> that are displayed when using *bin/solr.cmd* with the parameter *_-help_*.
> The items are listed in no particular order and may be addressed 
> independantly.
> To spot the differences between the Usage Messages of _bin/solr_ and 
> _bin/solr.cmd_ I compiled an extract of the Usage Messages of the two files 
> so that they can be compared using WinMerge or a similar diff tool.
> See the attached files *solr.cmd.txt* and *solr.txt*.
> Note that I work on a German Windows 10, therefore some error messages I 
> quote here are in German.
> # _solr_ _start_ _-help_ results in a syntax error
> The special characters '<' and '>' are not escaped.
> The line 314 must be changed as follows:
> {noformat}
> CURRENT : ... the default server/
> SHALL_BE: ... the default server/^
> {noformat}
> \\
> # _solr auth -help_ ends is empty
> A goto label ':auth_usage' with the appropriate Usage Messages already exists.
> At line 266 an additional if-statement is required.
> Also, a respective if-statement will be required on line 1858.
> {noformat}
> NEW_CODE: IF "%SCRIPT_CMD%"=="auth" goto auth_usage
> {noformat}
> Some additional bugs in the section ':auth_usage' must then also be addressed.
> The special character '|' is not escaped at a number of locations.
> The lines 568, 569, 570, 577, 580 and 585 must be changed, e.g.
> {noformat}
> CURRENT : echo Usage: solr auth enable [-type basicAuth] -credentials 
> user:pass [-blockUnknown ^] [-updateIncludeFileOnly 
> ^] [-V]
> SHALL_BE: echo Usage: solr auth enable [-type basicAuth] -credentials 
> user:pass [-blockUnknown ^] [-updateIncludeFileOnly 
> ^] [-V]
> {noformat}
> The empty 'echo' statement (i.e. 'newline') needs the be written with a dot 
> ('echo.') to avoid "ECHO ist ausgeschaltet (OFF)." statements.
> The lines 571, 573, 576, 577, 579, 584, 587, 589, 591, 594 and 596 must be 
> changed:
> {noformat}
> CURRENT : echo
> SHALL_BE: echo.
> {noformat}
> \\
> # _solr_ _-help_ does not mention the command _status_
> The line 271 must be changed as follows:
> {noformat}
> CURRENT : @echowhere COMMAND is one of: start, stop, restart, 
> healthcheck, create, create_core, create_collection, delete, version, zk, 
> auth, assert
> SHALL_BE: @echowhere COMMAND is one of: start, stop, restart, status, 
> healthcheck, create, create_core, create_collection, delete, version, zk, 
> auth, assert
> {noformat}
> \\
> # In _bin/solr.cmd_ the description of _solr_ _start_ _-p_ _port_ does not 
> mention the STOP_PORT and the RMI_PORT, see line 324 to 326 of _bin/solr_.
> {noformat}
> echo "  -p  Specify the port to start the Solr HTTP listener on; 
> default is 8983"
> echo "  The specified port (SOLR_PORT) will also be used to 
> determine the stop port"
> echo "  STOP_PORT=(\$SOLR_PORT-1000) and JMX RMI listen port 
> RMI_PORT=(\$SOLR_PORT+1). "
> echo "  For instance, if you set -p 8985, then the 
> STOP_PORT=7985 and RMI_PORT=18985"
> {noformat}
> \\
> # The description of _solr_ _start_ _-s_ _dir_ seems to have been revised in 
> _bin/solr.cmd_ but not in _bin/solr_.
> {noformat}
>   on which example is run. The default value is server/solr. 
> If passed a relative dir
>   validation with the current dir will be done before trying 
> the default server/
> {noformat}
> vs.
> {noformat}  
>   on which example is run. The default value is server/solr. 
> If passed relative dir,
>   validation with current dir will be done, before trying 
> default server/
> {noformat}
> \\
> # The description of _solr_ _start_ _-t_ _dir_ is different
> {noformat}
>   -t dirSets the solr.data.home system property, used as root for 
> ^/data directories.
>   If not set, Solr uses solr.solr.home for both config and 
> data.
> {noformat}
> vs.
> {noformat}
>   -t  

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

[Apache Jenkins Server]

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

No tests ran.

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

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

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 

[jira] [Commented] (SOLR-11840) Inconsistencies in the Usage Messages of bin/solr.cmd

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-11840:


Circling back to this now.  Running tests and will commit later today unless 
there are other issues.

> Inconsistencies in the Usage Messages of bin/solr.cmd
> -
>
> Key: SOLR-11840
> URL: https://issues.apache.org/jira/browse/SOLR-11840
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Jakob Furrer
>Priority: Major
>  Labels: documentation, easyfix
> Fix For: 7.2
>
> Attachments: SOLR-11840.patch, solr.cmd.txt, solr.txt, 
> solr_start_help_Syntaxfehler.png
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I noticed a number of errors/problems/peculiarities in the Usage Messages 
> that are displayed when using *bin/solr.cmd* with the parameter *_-help_*.
> The items are listed in no particular order and may be addressed 
> independantly.
> To spot the differences between the Usage Messages of _bin/solr_ and 
> _bin/solr.cmd_ I compiled an extract of the Usage Messages of the two files 
> so that they can be compared using WinMerge or a similar diff tool.
> See the attached files *solr.cmd.txt* and *solr.txt*.
> Note that I work on a German Windows 10, therefore some error messages I 
> quote here are in German.
> # _solr_ _start_ _-help_ results in a syntax error
> The special characters '<' and '>' are not escaped.
> The line 314 must be changed as follows:
> {noformat}
> CURRENT : ... the default server/
> SHALL_BE: ... the default server/^
> {noformat}
> \\
> # _solr auth -help_ ends is empty
> A goto label ':auth_usage' with the appropriate Usage Messages already exists.
> At line 266 an additional if-statement is required.
> Also, a respective if-statement will be required on line 1858.
> {noformat}
> NEW_CODE: IF "%SCRIPT_CMD%"=="auth" goto auth_usage
> {noformat}
> Some additional bugs in the section ':auth_usage' must then also be addressed.
> The special character '|' is not escaped at a number of locations.
> The lines 568, 569, 570, 577, 580 and 585 must be changed, e.g.
> {noformat}
> CURRENT : echo Usage: solr auth enable [-type basicAuth] -credentials 
> user:pass [-blockUnknown ^] [-updateIncludeFileOnly 
> ^] [-V]
> SHALL_BE: echo Usage: solr auth enable [-type basicAuth] -credentials 
> user:pass [-blockUnknown ^] [-updateIncludeFileOnly 
> ^] [-V]
> {noformat}
> The empty 'echo' statement (i.e. 'newline') needs the be written with a dot 
> ('echo.') to avoid "ECHO ist ausgeschaltet (OFF)." statements.
> The lines 571, 573, 576, 577, 579, 584, 587, 589, 591, 594 and 596 must be 
> changed:
> {noformat}
> CURRENT : echo
> SHALL_BE: echo.
> {noformat}
> \\
> # _solr_ _-help_ does not mention the command _status_
> The line 271 must be changed as follows:
> {noformat}
> CURRENT : @echowhere COMMAND is one of: start, stop, restart, 
> healthcheck, create, create_core, create_collection, delete, version, zk, 
> auth, assert
> SHALL_BE: @echowhere COMMAND is one of: start, stop, restart, status, 
> healthcheck, create, create_core, create_collection, delete, version, zk, 
> auth, assert
> {noformat}
> \\
> # In _bin/solr.cmd_ the description of _solr_ _start_ _-p_ _port_ does not 
> mention the STOP_PORT and the RMI_PORT, see line 324 to 326 of _bin/solr_.
> {noformat}
> echo "  -p  Specify the port to start the Solr HTTP listener on; 
> default is 8983"
> echo "  The specified port (SOLR_PORT) will also be used to 
> determine the stop port"
> echo "  STOP_PORT=(\$SOLR_PORT-1000) and JMX RMI listen port 
> RMI_PORT=(\$SOLR_PORT+1). "
> echo "  For instance, if you set -p 8985, then the 
> STOP_PORT=7985 and RMI_PORT=18985"
> {noformat}
> \\
> # The description of _solr_ _start_ _-s_ _dir_ seems to have been revised in 
> _bin/solr.cmd_ but not in _bin/solr_.
> {noformat}
>   on which example is run. The default value is server/solr. 
> If passed a relative dir
>   validation with the current dir will be done before trying 
> the default server/
> {noformat}
> vs.
> {noformat}  
>   on which example is run. The default value is server/solr. 
> If passed relative dir,
>   validation with current dir will be done, before trying 
> default server/
> {noformat}
> \\
> # The description of _solr_ _start_ _-t_ _dir_ is different
> {noformat}
>   -t dirSets the solr.data.home system property, used as root for 
> ^/data directories.
>   If not set, Solr 

[jira] [Created] (SOLR-12228) Integrate bin-test/test with Ant

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-12228:
--

 Summary: Integrate bin-test/test with Ant
 Key: SOLR-12228
 URL: https://issues.apache.org/jira/browse/SOLR-12228
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build, scripts and tools
Affects Versions: master (8.0)
Reporter: Jason Gerlowski


SOLR-11749 created a regression test suite for our {{bin/solr}} scripts, and 
SOLR-12137 expanded this coverage to Windows as well.

Now that we have a test suite on both Windows and *nix, we should create an 
{{ant}} target allowing devs to easily trigger these tests.  We should also 
consider whether there's community consensus behind adding these tests to 
existing runs of {{ant test}}.  If there are concrete but fixable things 
preventing {{ant test}} integration, we should fix those.



--
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-12227) Add bin-test/test coverage for bin/solr start/stop/restart

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-12227:
---
Summary: Add bin-test/test coverage for bin/solr start/stop/restart  (was: 
Add bin/test coverage for bin/solr start/stop/restart)

> Add bin-test/test coverage for bin/solr start/stop/restart
> --
>
> Key: SOLR-12227
> URL: https://issues.apache.org/jira/browse/SOLR-12227
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
>
> SOLR-11749 introduced a regression-test-suite for the {{bin/solr}} scripts.  
> This is one of a series of follow-on issues to expand the test coverage in 
> this suite to cover more of the {{SolrCLI}} tools made available by 
> {{bin/solr}}
> This issue focused specifically on adding coverage for the start, stop, and 
> restart commands to {{bin/solr}}.  Expanding this coverage is important for 
> future refactors or additions to the bin/solr scripts, such as porting more 
> of the logic back to Java code (SOLR-11206, SOLR-11946), or unifying the 
> solr.in.* files used on Solr startup (SOLR-7871)



--
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-12226) Add bin-test/test coverage for bin/solr zk functionality

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-12226:
---
Summary: Add bin-test/test coverage for bin/solr zk functionality  (was: 
Add bin/test coverage for bin/solr zk functionality)

> Add bin-test/test coverage for bin/solr zk functionality
> 
>
> Key: SOLR-12226
> URL: https://issues.apache.org/jira/browse/SOLR-12226
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
>
> SOLR-11749 introduced a regression-test-suite for the {{bin/solr}} scripts.  
> This is one of a series of follow-on issues to expand the test coverage in 
> this suite to cover more of the {{SolrCLI}} tools made available by 
> {{bin/solr}}
> This issue focused specifically on adding coverage for the {{bin/solr zk}} 
> tool.  Expanding this coverage is important for future refactors or additions 
> to the bin/solr scripts, such as porting more of the logic back to Java code 
> (SOLR-11206, SOLR-11946), or unifying the solr.in.* files used on Solr 
> startup (SOLR-7871)



--
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-12225) Add bin-test/test coverage for bin/solr auth functionality

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-12225:
---
Summary: Add bin-test/test coverage for bin/solr auth functionality  (was: 
Add bin/test coverage for bin/solr auth functionality)

> Add bin-test/test coverage for bin/solr auth functionality
> --
>
> Key: SOLR-12225
> URL: https://issues.apache.org/jira/browse/SOLR-12225
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
>
> SOLR-11749 introduced a regression-test-suite for the {{bin/solr}} scripts.  
> This is one of a series of follow-on issues to expand the test coverage in 
> this suite to cover more of the {{SolrCLI}} tools made available by 
> {{bin/solr}}
> This issue focused specifically on adding coverage for the {{bin/solr auth}} 
> tool.  Expanding this coverage is important for future refactors or additions 
> to the bin/solr scripts, such as porting more of the logic back to Java code 
> (SOLR-11206, SOLR-11946), or unifying the solr.in.* files used on Solr 
> startup (SOLR-7871)



--
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-12227) Add bin/test coverage for bin/solr start/stop/restart

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-12227:
--

 Summary: Add bin/test coverage for bin/solr start/stop/restart
 Key: SOLR-12227
 URL: https://issues.apache.org/jira/browse/SOLR-12227
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: master (8.0)
Reporter: Jason Gerlowski


SOLR-11749 introduced a regression-test-suite for the {{bin/solr}} scripts.  
This is one of a series of follow-on issues to expand the test coverage in this 
suite to cover more of the {{SolrCLI}} tools made available by {{bin/solr}}

This issue focused specifically on adding coverage for the start, stop, and 
restart commands to {{bin/solr}}.  Expanding this coverage is important for 
future refactors or additions to the bin/solr scripts, such as porting more of 
the logic back to Java code (SOLR-11206, SOLR-11946), or unifying the solr.in.* 
files used on Solr startup (SOLR-7871)




--
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-12226) Add bin/test coverage for bin/solr zk functionality

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-12226:
--

 Summary: Add bin/test coverage for bin/solr zk functionality
 Key: SOLR-12226
 URL: https://issues.apache.org/jira/browse/SOLR-12226
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: master (8.0)
Reporter: Jason Gerlowski


SOLR-11749 introduced a regression-test-suite for the {{bin/solr}} scripts.  
This is one of a series of follow-on issues to expand the test coverage in this 
suite to cover more of the {{SolrCLI}} tools made available by {{bin/solr}}

This issue focused specifically on adding coverage for the {{bin/solr zk}} 
tool.  Expanding this coverage is important for future refactors or additions 
to the bin/solr scripts, such as porting more of the logic back to Java code 
(SOLR-11206, SOLR-11946), or unifying the solr.in.* files used on Solr startup 
(SOLR-7871)




--
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: Next steps for Solr Admin UI - request for in-depth discussion

[Upayavira]

On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote:
> Hello,
> 
> The relevant JIRA is SOLR-12196, but we felt this deserved a greater 
> discussion.
> 
> Basically, our Admin UI is currently using AngularJS (1.x) as its
> Javascript framework. That particular library has reached its
> evolutionary end long time ago and is about to stop being supported
> all together. The later versions of Angular carry the same name, but
> are _very_ _very_ different. So, despite the heroic efforts that got
> us here, we are facing this choice again. Also, as we were just trying
> to migrate the UI and not rethink it, the underlying design/file
> layout/plugin architecture is also quite problematic.
> 
> The question is what is the right thing to do next. There are
> basically four options:
> 1) Migrate to the latest Angular in an incremental fashion (as per
> JIRA's original proposal)
> 2) Jump to a different library (such as React or Vue) which got a much
> stronger momentum and ecosystem these days, but sort of keep current
> architecture (UI feel/approach)
> 3) Go blue-sky with new library and actually put some deep thought
> into modern UI leveraging Solr's current features (Management API,
> JSON, etc). Also, by picking React (for example) we get access to the
> ecosystem of modern tools, extensions and even potentially mobile
> apps.
> 4) Drop our own UI and adopt somebody else's (I don't have any good
> suggestions here though)?
> 
> Normally, option 1 would be the sane one. The challenge is two fold though:
> a) Even option 1 is a lot of work due the Angular team's radical
> change of direction. Enough that it will lock us out from any other
> option for at least another 3-4 years.
> b) We are all server-side developers. So, even the simple Javascript
> things are hard for us, never mind the CSS part. So, this makes the
> cost of starting with any new approach dis-proportionally hard. Once
> going, it is a bit easier, because the advanced concepts are similar
> to other languages.
> 
> All of these, combined with all the open JIRAs on Admin issues - to me
> - make option 3 less crazy than usual.
> 
> What do others think? Is there discontent with the current state of
> Admin UI (apart from the implementation choice)? Are there secret web
> designers here, willing to get us over a bump of migration? Is there a
> company out there, willing to sponsor relevant skills to let us
> leapfrog the incremental upgrade (similar to how we got the Reference
> Guide).

As you know, I'm responsible for the current UI. The aims in building this 
version of the UI were to keep the visuals entirely the same, whilst reducing 
the size and complexity of the underlying JavaScript (we reduced it by about 
50% in terms of LoC). The bulk of the work in its implementation was in terms 
of understanding the intent of the existing code. Reproducing it in new code 
was a smaller task by comparison. I hope this will pay off in any future 
rewrite.

At the time, the JavaScript landscape was changing fast. It was clear that 
anything we produced would only be valid for a number of years. It seems we 
have now reached that limit.

I have recently taught myself basic ReactJS. It is clearly a powerful beast. 
The two major distinguishing factors from the current UI are its componentised 
nature (which means you don't build pages, you build re-usable components) and 
that it uses a transpiled language. 

To rebuild the current UI in React, we would need to decompose the HTML pages 
into components, and migrate behaviour into those components.

Using a transpiled language (and all the tools that support that, e.g. webpack) 
would give us a more compact, and modern, UI.

However, the HTML is growing old. It isn't properly responsive, and it doesn't 
use idioms that people have come to expect from a UI (e.g. no hamburgers).

In theory, I would support a rewrite of the visuals - it would make Solr seem 
more modern. However, I do not underestimate the amount of work involved.

Upayavira

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

[jira] [Created] (SOLR-12225) Add bin/test coverage for bin/solr auth functionality

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-12225:
--

 Summary: Add bin/test coverage for bin/solr auth functionality
 Key: SOLR-12225
 URL: https://issues.apache.org/jira/browse/SOLR-12225
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: master (8.0)
Reporter: Jason Gerlowski


SOLR-11749 introduced a regression-test-suite for the {{bin/solr}} scripts.  
This is one of a series of follow-on issues to expand the test coverage in this 
suite to cover more of the {{SolrCLI}} tools made available by {{bin/solr}}

This issue focused specifically on adding coverage for the {{bin/solr auth}} 
tool.  Expanding this coverage is important for future refactors or additions 
to the bin/solr scripts, such as porting more of the logic back to Java code 
(SOLR-11206, SOLR-11946), or unifying the solr.in.* files used on Solr startup 
(SOLR-7871)



--
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 # 495 - Unstable

[Apache Jenkins Server]

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

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

[repro] Revision: e541ed89f3e2968e0a4497035aaa42614d050e8d

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestReplicationHandler 
-Dtests.method=doTestReplicateAfterCoreReload -Dtests.seed=DAFFDC8E84BA5E7B 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=no-NO -Dtests.timezone=America/Argentina/Mendoza 
-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: 
dad2d1076db632535c33fa118eb851ad7d0e2537
[repro] git fetch
[repro] git checkout e541ed89f3e2968e0a4497035aaa42614d050e8d

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

[...truncated 3312 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestReplicationHandler" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=DAFFDC8E84BA5E7B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=no-NO -Dtests.timezone=America/Argentina/Mendoza 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   4/5 failed: org.apache.solr.handler.TestReplicationHandler
[repro] git checkout dad2d1076db632535c33fa118eb851ad7d0e2537

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

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 37 - Still unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth

Error Message:
Error from server at https://127.0.0.1:38520/solr: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-02

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:38520/solr: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-02
at 
__randomizedtesting.SeedInfo.seed([C0827DA6B301569D:3C38A9924B21E757]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:200)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:188)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:138)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:110)
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 

[jira] [Commented] (SOLR-12224) there is no API to read collection properties

[Hendrik Haddorp (JIRA)]

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

Hendrik Haddorp commented on SOLR-12224:


As the clusterstatus contains the cluster properties already it would make 
sense to me to also include the collection properties.

> there is no API to read collection properties
> -
>
> Key: SOLR-12224
> URL: https://issues.apache.org/jira/browse/SOLR-12224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.3
>Reporter: Hendrik Haddorp
>Priority: Major
>
> Solr 7.3 added the COLLECTIONPROP API call 
> (https://lucene.apache.org/solr/guide/7_3/collections-api.html#collectionprop)
>  that allows to set arbitrary properties on a collection. There is however no 
> API call that returns the data. The only option is to manually read out the 
> collectionprops.json file in ZK below the collection.
> Options could be that the COLLECTIONPROP command has an option to retrieve 
> properties, have a special command to list the properties and/or to have the 
> properties listed in the clusterstatus output for a collection.
> Would be great if SolrJ would also be supported.



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

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

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

[Policeman Jenkins Server]

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

java.lang.OutOfMemoryError: Java heap space

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