[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+24) - Build # 22586 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22586/
Java: 64bit/jdk-11-ea+24 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

26 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.SchemaApiFailureTest

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at __randomizedtesting.SeedInfo.seed([9BAE8AF1D089A216]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1469)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:450)
at 
org.apache.solr.schema.SchemaApiFailureTest.setupCluster(SchemaApiFailureTest.java:43)
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:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
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:834)


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.SchemaApiFailureTest

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at __randomizedtesting.SeedInfo.seed([9BAE8AF1D089A216]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1469)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:450)
at 
org.apache.solr.schema.SchemaApiFailureTest.setupCluster(SchemaApiFailureTest.java:43)
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:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
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)
  

[jira] [Updated] (SOLR-12617) Remove Commons BeanUtils as a dependency

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12617:
-
Fix Version/s: 7.5
   master (8.0)

> Remove Commons BeanUtils as a dependency
> 
>
> Key: SOLR-12617
> URL: https://issues.apache.org/jira/browse/SOLR-12617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12617.patch
>
>
> The BeanUtils library is a dependency in the velocity contrib module.
> It is a compile time dependency but the velocity code that Solr uses doesn't 
> leverage any of this.
> After removing the dependency Solr compiles just fine and the browse handler 
> also loads up correctly. 
> While chatting to [~ehatcher] offline he confirmed that the tests also pass 
> without this dependency.
> The main motivation behind this is a long standing CVE against bean-utils 
> 1.8.3 ( 
> [https://nvd.nist.gov/vuln/detail/CVE-2014-0114#vulnCurrentDescriptionTitle] 
> ) which to my knowledge cannot be leveraged from how we use it in Solr . But 
> security scans still pick it up so if it's not being used we should simply 
> remove it.



--
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-12617) Remove Commons BeanUtils as a dependency

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12617:
--

After the patch , [http://localhost:8983/solr/techproducts/browse] works just 
fine.

If there are no objections I'll commit this tomorrow 

> Remove Commons BeanUtils as a dependency
> 
>
> Key: SOLR-12617
> URL: https://issues.apache.org/jira/browse/SOLR-12617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12617.patch
>
>
> The BeanUtils library is a dependency in the velocity contrib module.
> It is a compile time dependency but the velocity code that Solr uses doesn't 
> leverage any of this.
> After removing the dependency Solr compiles just fine and the browse handler 
> also loads up correctly. 
> While chatting to [~ehatcher] offline he confirmed that the tests also pass 
> without this dependency.
> The main motivation behind this is a long standing CVE against bean-utils 
> 1.8.3 ( 
> [https://nvd.nist.gov/vuln/detail/CVE-2014-0114#vulnCurrentDescriptionTitle] 
> ) which to my knowledge cannot be leveraged from how we use it in Solr . But 
> security scans still pick it up so if it's not being used we should simply 
> remove it.



--
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-12617) Remove Commons BeanUtils as a dependency

[Varun Thacker (JIRA)]

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

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

> Remove Commons BeanUtils as a dependency
> 
>
> Key: SOLR-12617
> URL: https://issues.apache.org/jira/browse/SOLR-12617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
> Attachments: SOLR-12617.patch
>
>
> The BeanUtils library is a dependency in the velocity contrib module.
> It is a compile time dependency but the velocity code that Solr uses doesn't 
> leverage any of this.
> After removing the dependency Solr compiles just fine and the browse handler 
> also loads up correctly. 
> While chatting to [~ehatcher] offline he confirmed that the tests also pass 
> without this dependency.
> The main motivation behind this is a long standing CVE against bean-utils 
> 1.8.3 ( 
> [https://nvd.nist.gov/vuln/detail/CVE-2014-0114#vulnCurrentDescriptionTitle] 
> ) which to my knowledge cannot be leveraged from how we use it in Solr . But 
> security scans still pick it up so if it's not being used we should simply 
> remove it.



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

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 279 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/279/

1 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_stored_idx

Error Message:
Some docs had errors -- check logs expected:<0> but was:<1>

Stack Trace:
java.lang.AssertionError: Some docs had errors -- check logs expected:<0> but 
was:<1>
at 
__randomizedtesting.SeedInfo.seed([FD6FF94EED76E512:ED0E54B7F8D4A03C]: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.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:343)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_stored_idx(TestStressCloudBlindAtomicUpdates.java:242)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:

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

[Policeman Jenkins Server]

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

9 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([E2942439C7EB388F]:0)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.createMiniSolrCloudCluster(TestStressCloudBlindAtomicUpdates.java:138)
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$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


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

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([E2942439C7EB388F]:0)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.afterClass(TestStressCloudBlindAtomicUpdates.java:158)
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$7.evaluate(RandomizedRunner.java:897)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 277 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/277/

No tests ran.

Build Log:
[...truncated 23037 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: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of 
sequence: expected level 2, got level 3
 [java] Processed 2239 links (1792 relative) to 3016 anchors in 230 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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-7.x/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.5.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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-7.x/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-7.x/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-7.x/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-7.x/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-7.x/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] [Created] (SOLR-12617) Remove Commons BeanUtils as a dependency

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12617:


 Summary: Remove Commons BeanUtils as a dependency
 Key: SOLR-12617
 URL: https://issues.apache.org/jira/browse/SOLR-12617
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


The BeanUtils library is a dependency in the velocity contrib module.

It is a compile time dependency but the velocity code that Solr uses doesn't 
leverage any of this.

After removing the dependency Solr compiles just fine and the browse handler 
also loads up correctly. 

While chatting to [~ehatcher] offline he confirmed that the tests also pass 
without this dependency.

The main motivation behind this is a long standing CVE against bean-utils 1.8.3 
( [https://nvd.nist.gov/vuln/detail/CVE-2014-0114#vulnCurrentDescriptionTitle] 
) which to my knowledge cannot be leveraged from how we use it in Solr . But 
security scans still pick it up so if it's not being used we should simply 
remove it.



--
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-12616) Track down performance slowdowns with ExportWriter

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12616:


 Summary: Track down performance slowdowns with ExportWriter
 Key: SOLR-12616
 URL: https://issues.apache.org/jira/browse/SOLR-12616
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


Just to be clear for users glancing through this Jira : The performance 
slowdown is currently on an unreleased version of Solr so no versions are 
affected by this.

While doing some benchmarking for SOLR-12572 , I compared the export writers 
performance against Solr 7.4 and there seems to be some slowdowns that have 
been introduced. Most likely this is because of SOLR-11598

In an 1 shard 1 replica collection with 25M docs. We issue the following query 
{code:java}
/export?q=*:*=id desc=id{code}
Solr 7.4 took 8:10 , 8:20 and 8:22 in the 3 runs that I did

Master took 10:46

Amrit's done some more benchmarking so he can fill in with some more numbers 
here. 

 



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

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

[jira] [Created] (SOLR-12615) Search stream throws an NPE with partitionKeys and empty values

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12615:


 Summary: Search stream throws an NPE with partitionKeys and empty 
values
 Key: SOLR-12615
 URL: https://issues.apache.org/jira/browse/SOLR-12615
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.4
Reporter: Varun Thacker


If I index documents where the partitionKeys keys field is missing from a few 
docs then the stream expression throws an NPE

docs:
{code:java}
[
{"id" : "1", "search_term_s" : "query1"},
{"id" : "2", "search_term_s" : "query1"},
{"id" : "3"},
{"id" : "4"}
]{code}
 

query
{code:java}
search(test_empty, q="*:*", fl="search_term_s,id" , sort="search_term_s desc", 
qt="/export", partitionKeys="search_term_s"){code}
 

logs
{code:java}
INFO - 2018-08-03 01:44:36.156; [c:test_empty s:shard1 r:core_node2 
x:test_empty_shard1_replica_n1] org.apache.solr.core.SolrCore.Request; 
[test_empty_shard1_replica_n1] webapp=/solr path=/stream 
params={expr=search(test_empty,+q%3D"*:*",+fl%3D"search_term_s,id"+,+sort%3D"search_term_s+desc",+qt%3D"/export",+partitionKeys%3D"search_term_s")&_=1533260573672}
 status=0 QTime=11
INFO - 2018-08-03 01:44:36.160; [ ] 
org.apache.solr.common.cloud.ConnectionManager; zkClient has connected
INFO - 2018-08-03 01:44:36.162; [c:test_empty s:shard1 r:core_node2 
x:test_empty_shard1_replica_n1] org.apache.solr.common.cloud.ZkStateReader; 
Updated live nodes from ZooKeeper... (0) -> (1)
INFO - 2018-08-03 01:44:36.164; [c:test_empty s:shard1 r:core_node2 
x:test_empty_shard1_replica_n1] 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider; Cluster at 
localhost:9888 ready
INFO - 2018-08-03 01:44:36.207; [c:test_empty s:shard1 r:core_node2 
x:test_empty_shard1_replica_n1] org.apache.solr.core.SolrCore.Request; 
[test_empty_shard1_replica_n1] webapp=/solr path=/export 
params={q=*:*=false=off=search_term_s,id=search_term_s+desc=search_term_s={!hash+workers%3D1+worker%3D0}=json=2.2}
 status=500 QTime=36
ERROR - 2018-08-03 01:44:36.209; [c:test_empty s:shard1 r:core_node2 
x:test_empty_shard1_replica_n1] org.apache.solr.servlet.HttpSolrCall; 
null:java.io.IOException: java.lang.RuntimeException: 
java.lang.NullPointerException
at 
org.apache.solr.search.HashQParserPlugin$HashQuery.createWeight(HashQParserPlugin.java:130)
at org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:743)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:463)
at org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:151)
at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:140)
at 
org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1196)
at 
org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:836)
at 
org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1044)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1563)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1439)
at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:586)
at 
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1435)
at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:375)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
at 
org.apache.solr.handler.ExportHandler.handleRequestBody(ExportHandler.java:37)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2539)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
at 

[jira] [Resolved] (SOLR-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch resolved SOLR-12574.
--
Resolution: Fixed

Fix backported.

> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 7.5
>
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not 
> documented or spelt correctly in 7.4), so there is still a chance to fix its 
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level 
> as responseHeader and response. This feels like polluting top-level space. It 
> may be better to put all those keys under one bucket (e.g. significantTerms). 
> Additionally, resultCount is always the same as response.numFound (documents 
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
>     "responseHeader": {
>     "status": 0,
>     "QTime": 1,
>     "params": {
>     "q": "directed_by_str:\"Steven Soderbergh\"",
>     "fq": "{!significantTerms field=genre numTerms=2}",
>     "rows": "1",
>     "wt": "json"
>     }
>     },
>     "numDocs": 1100,
>     "resultCount": 5,
>     "sterms": [
>     "biographical",
>     "romance"
>     ],
>     "scores": [
>     2.5552773475646973,
>     2.6387078762054443
>     ],
>     "docFreq": [
>     74,
>     270
>     ],
>     "queryDocFreq": [
>     2,
>     3
>     ],
>     "response": {
>     "numFound": 5,
>     "start": 0,
>     "docs": [
>     {
>     "id": "/en/bubble",
>     "directed_by": [
>     "Steven Soderbergh"
>     ],
>     "initial_release_date": "2005-09-03T00:00:00Z",
>     "name": "Bubble",
>     "genre": [
>     "Crime Fiction",
>     "Mystery",
>     "Indie film",
>     "Thriller",
>     "Drama"
>     ],
>     "_version_": 1606610059993808899
>     }
>     ]
>     }
> }{code}



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

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

[jira] [Commented] (SOLR-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12572:
--

I did some testing on my local machine. The collection was 1 shard 1 replica. 
The collection has 25M docs where {{number_i}} was 1 though 25M .
{code:java}
http://localhost:8983/solr/test_export/export?q=*:*=number_i 
desc=number_i{code}
Results from 2 runs shows a ~30% improvement.  

without patch : 886s , 866s
with patch : 664s , 674s

The worrying thing though is that 7.4 is faster than master. I suspect that has 
something to do with SOLR-11598 . I'm creating a new Jira to track that 
slowdown .

This patch looks good to me otherwise so I plan on committing it in the next 
few days

> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch, 
> SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query=severity+desc,timestamp+desc=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example 
> 'severity, 'timestamp'). When we stream out docs we again make doc-value 
> seeks against the {{fl}} fields ('severity','timestamp','msg') . 
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort 
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values 
> while sorting it, we can reduce the doc-value seeks potentially bringing 
> *speed improvement*.



--
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-12574) SignificantTermsQParserPlugin should output its keys in a combined bucket

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12574:


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

SOLR-12574: Fix the SignificantTermStream to use the new bucket format


> SignificantTermsQParserPlugin should output its keys in a combined bucket
> -
>
> Key: SOLR-12574
> URL: https://issues.apache.org/jira/browse/SOLR-12574
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.4
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 7.5
>
> Attachments: SOLR-12574.patch
>
>
> SignificantTermsQParserPlugin is not yet visible to the users (was not 
> documented or spelt correctly in 7.4), so there is still a chance to fix its 
> output before people start using it.
> Currently, it injects 6 different keys into the document, on the same level 
> as responseHeader and response. This feels like polluting top-level space. It 
> may be better to put all those keys under one bucket (e.g. significantTerms). 
> Additionally, resultCount is always the same as response.numFound (documents 
> found), so does not seem to be needed.
> Current output:
> {code:java}
> {
>     "responseHeader": {
>     "status": 0,
>     "QTime": 1,
>     "params": {
>     "q": "directed_by_str:\"Steven Soderbergh\"",
>     "fq": "{!significantTerms field=genre numTerms=2}",
>     "rows": "1",
>     "wt": "json"
>     }
>     },
>     "numDocs": 1100,
>     "resultCount": 5,
>     "sterms": [
>     "biographical",
>     "romance"
>     ],
>     "scores": [
>     2.5552773475646973,
>     2.6387078762054443
>     ],
>     "docFreq": [
>     74,
>     270
>     ],
>     "queryDocFreq": [
>     2,
>     3
>     ],
>     "response": {
>     "numFound": 5,
>     "start": 0,
>     "docs": [
>     {
>     "id": "/en/bubble",
>     "directed_by": [
>     "Steven Soderbergh"
>     ],
>     "initial_release_date": "2005-09-03T00:00:00Z",
>     "name": "Bubble",
>     "genre": [
>     "Crime Fiction",
>     "Mystery",
>     "Indie film",
>     "Thriller",
>     "Drama"
>     ],
>     "_version_": 1606610059993808899
>     }
>     ]
>     }
> }{code}



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

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

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

[Policeman Jenkins Server]

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

46 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.graph.GraphTest

Error Message:
Error from server at https://127.0.0.1:36019/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:36019/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([497CAC0FD2754553]: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.client.solrj.io.graph.GraphTest.setupCluster(GraphTest.java:62)
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$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.graph.GraphTest

Error Message:
Captured an uncaught exception in thread: Thread[id=263, 
name=OverseerAutoScalingTriggerThread-72094273463255044-127.0.0.1:34957_solr-n_00,
 state=RUNNABLE, group=Overseer autoscaling triggers]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=263, 
name=OverseerAutoScalingTriggerThread-72094273463255044-127.0.0.1:34957_solr-n_00,
 state=RUNNABLE, group=Overseer autoscaling triggers]
Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
org.apache.solr.client.solrj.cloud.autoscaling.VariableBase
at __randomizedtesting.SeedInfo.seed([497CAC0FD2754553]:0)
at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy.(Policy.java:127)
at 

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

ASF subversion and git services commented on SOLR-12028:


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

SOLR-12028: BadApple and AwaitsFix annotations usage

(cherry picked from commit 6afd3d11929a75e3b3310638b32f4ed55da3ea6e)


> 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

Re: Keeping RefGuide screenshots up to date

[Alexandre Rafalovitch]

That sounds good.

And, from a quick look, the Asciidoc screenshot tool uses Geb, which
uses Selenium as well (WebDriver anyway). So, maybe there is a clear
path somewhere in there.

Regards,
   Alex.


On 2 August 2018 at 19:01, Jan Høydahl  wrote:
> Neither though I think will get a collection into the correct pre-populated
> state
>
>
> We already have JUnit, so we could write a new test suite for UI testing,
> perhaps
> one that is not run by default, but has its own ant targer? Using JUnit we
> can
> pre-populate Solr clusters. The SolrUITestBase class could have conveience
> methods to create collections, feed example docs etc.
>
> Then, using Selenium webdriver as part of a JUnit test, we can navigate to
> the
> exact location in the UI we need, asserting various things along the way,
> and
> finally we can do screenshots of the whole page or limited to a CSS
> selector.
> See http://www.baeldung.com/java-selenium-with-junit-and-testng
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 2. aug. 2018 kl. 16:15 skrev Alexandre Rafalovitch :
>
> +1 as I think it would open up other example/documentation options.
>
> Chrome driver by itself may be sufficient for just sample screenshots,
> but Selenium may be better for testing and more advanced use-cases.
> Neither though I think will get a collection into the correct
> pre-populated state. So that would still need to be figured out (maybe
> something like Postman: https://www.getpostman.com/postman ).
>
> I think it would also go hand-in-hand with improving examples, so the
> screenshots are taken of something users could also use/reproduce.
> And/or with longer "getting started" example that could be automated
> with screenshots along the way.
>
> Regards,
>   Alex.
>
> On 2 August 2018 at 06:37, Jan Høydahl  wrote:
>
> In SOLR-12613 we'll rename the "Cloud" menu in Admin UI to "Cluster". This
> affects pretty much
> all admin UI screenshots in the Reference Guide, so the next question then
> is "How do we
> keep all those screenshots up to date?". I counted a total of 42 screen
> shots of the UI, many
> which require creating collections, adding data, typing things into the UI
> etc up front.
>
> Due to the work involved, we often tend to update only a few shots and leave
> others as-is even
> if they are inaccurate. Example is the new "Suggestions" menu tab - there
> are 27 screen
> shots in the ref guide which are not updated with that menu option.
>
> For SOLR-12613 I'm tempted to only update the four images in "cloud-screens"
> folder for now.
>
> Perhaps for the future an automated approach can be taken using Selenium, as
> outlined in
> this post:
> https://blog.codeship.com/automating-screenshots-in-documentation/ This
> could
> in first phase be a standalone tool to generate screenshots but could also
> be extended with
> other tests to get some validation of the UI itself, which is completely
> lacking today. WDYT?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

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

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.MultiThreadedOCPTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([D73BE9B9F5FF92F7:5F6FD6635B03FF0F]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testFillWorkQueue(MultiThreadedOCPTest.java:113)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:1008)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
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 

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

ASF subversion and git services commented on SOLR-12028:


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

SOLR-12028: BadApple and AwaitsFix annotations usage


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



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

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

[jira] [Commented] (LUCENE-8440) Add support for indexing and searching Line and Point shapes using LatLonShape encoding

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8440: Add support for indexing and searching Line and Point shapes using 
LatLonShape encoding


> Add support for indexing and searching Line and Point shapes using 
> LatLonShape encoding
> ---
>
> Key: LUCENE-8440
> URL: https://issues.apache.org/jira/browse/LUCENE-8440
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8440.patch, LUCENE-8440.patch
>
>
> This feature adds support to {{LatLonShape}} for indexing {{Line}} and 
> {{latitude, longitude}} Point types using the 6 dimension Triangle encoding 
> in {{LatLonShape}}. Indexed points and lines will be searchable using 
> {{LatLonShapeBoundingBoxQuery}} and the new {{LatLonShapePolygonQuery}} in 
> LUCENE-8435.



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

[JIRA]

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

Jan Høydahl commented on SOLR-8207:
---

What does "very basic" mean here? Version 5.1 perhaps? Then I need to revert my 
use of {{let}} and {{const}} to {{var}} as well...

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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: Keeping RefGuide screenshots up to date

[Jan Høydahl]

> Neither though I think will get a collection into the correct pre-populated 
> state

We already have JUnit, so we could write a new test suite for UI testing, 
perhaps
one that is not run by default, but has its own ant targer? Using JUnit we can 
pre-populate Solr clusters. The SolrUITestBase class could have conveience
methods to create collections, feed example docs etc.

Then, using Selenium webdriver as part of a JUnit test, we can navigate to the
exact location in the UI we need, asserting various things along the way, and
finally we can do screenshots of the whole page or limited to a CSS selector.
See http://www.baeldung.com/java-selenium-with-junit-and-testng 


--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 2. aug. 2018 kl. 16:15 skrev Alexandre Rafalovitch :
> 
> +1 as I think it would open up other example/documentation options.
> 
> Chrome driver by itself may be sufficient for just sample screenshots,
> but Selenium may be better for testing and more advanced use-cases.
> Neither though I think will get a collection into the correct
> pre-populated state. So that would still need to be figured out (maybe
> something like Postman: https://www.getpostman.com/postman ).
> 
> I think it would also go hand-in-hand with improving examples, so the
> screenshots are taken of something users could also use/reproduce.
> And/or with longer "getting started" example that could be automated
> with screenshots along the way.
> 
> Regards,
>   Alex.
> 
> On 2 August 2018 at 06:37, Jan Høydahl  wrote:
>> In SOLR-12613 we'll rename the "Cloud" menu in Admin UI to "Cluster". This 
>> affects pretty much
>> all admin UI screenshots in the Reference Guide, so the next question then 
>> is "How do we
>> keep all those screenshots up to date?". I counted a total of 42 screen 
>> shots of the UI, many
>> which require creating collections, adding data, typing things into the UI 
>> etc up front.
>> 
>> Due to the work involved, we often tend to update only a few shots and leave 
>> others as-is even
>> if they are inaccurate. Example is the new "Suggestions" menu tab - there 
>> are 27 screen
>> shots in the ref guide which are not updated with that menu option.
>> 
>> For SOLR-12613 I'm tempted to only update the four images in "cloud-screens" 
>> folder for now.
>> 
>> Perhaps for the future an automated approach can be taken using Selenium, as 
>> outlined in
>> this post: 
>> https://blog.codeship.com/automating-screenshots-in-documentation/ This could
>> in first phase be a standalone tool to generate screenshots but could also 
>> be extended with
>> other tests to get some validation of the UI itself, which is completely 
>> lacking today. WDYT?
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (SOLR-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=16567560#comment-16567560
 ] 

Upayavira commented on SOLR-8207:
-

Because we don't transpile our sources, we need to use a very basic JavaScript. 
To use later stuff, we would need to add a transpile stage to our build 
process. That wouldn't be a bad thing, we could add modification too, but it 
would be a reasonable size task.

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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

[jira] [Commented] (LUCENE-8440) Add support for indexing and searching Line and Point shapes using LatLonShape encoding

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8440: Add support for indexing and searching Line and Point shapes using 
LatLonShape encoding


> Add support for indexing and searching Line and Point shapes using 
> LatLonShape encoding
> ---
>
> Key: LUCENE-8440
> URL: https://issues.apache.org/jira/browse/LUCENE-8440
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8440.patch, LUCENE-8440.patch
>
>
> This feature adds support to {{LatLonShape}} for indexing {{Line}} and 
> {{latitude, longitude}} Point types using the 6 dimension Triangle encoding 
> in {{LatLonShape}}. Indexed points and lines will be searchable using 
> {{LatLonShapeBoundingBoxQuery}} and the new {{LatLonShapePolygonQuery}} in 
> LUCENE-8435.



--
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-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12572:

Attachment: (was: slowness.patch)

> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch, 
> SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query=severity+desc,timestamp+desc=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example 
> 'severity, 'timestamp'). When we stream out docs we again make doc-value 
> seeks against the {{fl}} fields ('severity','timestamp','msg') . 
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort 
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values 
> while sorting it, we can reduce the doc-value seeks potentially bringing 
> *speed improvement*.



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

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

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

[Policeman Jenkins Server]

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

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (SOLR-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter

[Lucene/Solr QA (JIRA)]

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

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

| (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 
12s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m  
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m  5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m  5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m  5s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 42m  3s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 46m 24s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.handler.export.TestExportWriter |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12572 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12934173/slowness.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu 
Jun 14 13:51:47 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 / b5ed635 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/158/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/158/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/158/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch, 
> SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch, slowness.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query=severity+desc,timestamp+desc=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example 
> 'severity, 'timestamp'). When we stream out docs we again make doc-value 
> seeks against the {{fl}} fields ('severity','timestamp','msg') . 
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort 
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values 
> while sorting it, we can reduce the doc-value seeks potentially bringing 
> *speed improvement*.



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

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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.api.collections.CollectionTooManyReplicasTest.testAddTooManyReplicas

Error Message:
Could not load collection from ZK: TooManyReplicasInSeveralFlavors

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
TooManyReplicasInSeveralFlavors
at 
__randomizedtesting.SeedInfo.seed([371FEA652E7E18EE:BA4D9EBD6098275F]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1316)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:732)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:117)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:256)
at 
org.apache.solr.cloud.api.collections.CollectionTooManyReplicasTest.getAllNodeNames(CollectionTooManyReplicasTest.java:218)
at 
org.apache.solr.cloud.api.collections.CollectionTooManyReplicasTest.testAddTooManyReplicas(CollectionTooManyReplicasTest.java:63)
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 

Re: G1GC collector warning on JavaBugs page

[Walter Underwood]

We’ve had G1GC in production with 6.6.2 for nearly a year with Java 1.8.0_121. 
No issues.

That is a 32 node cluster of 36 CPU instances with 1-2 million queries per day. 

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Aug 2, 2018, at 2:00 PM, David Smiley  wrote:
> 
> +1
> 
> On Thu, Aug 2, 2018 at 3:15 PM Erick Erickson  > wrote:
> There's still the very firm warning _not_ to use the G1GC collector,
> and a link to https://bugs.openjdk.java.net/browse/JDK-8038348 
>  which
> is marked as fixed "7u25, 8, 9". Should we remove that warning at this
> point?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

Re: G1GC collector warning on JavaBugs page

[David Smiley]

+1

On Thu, Aug 2, 2018 at 3:15 PM Erick Erickson 
wrote:

> There's still the very firm warning _not_ to use the G1GC collector,
> and a link to https://bugs.openjdk.java.net/browse/JDK-8038348 which
> is marked as fixed "7u25, 8, 9". Should we remove that warning at this
> point?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Updated] (SOLR-12572) Reuse fieldvalues computed while sorting at writing in ExportWriter

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12572:

Attachment: slowness.patch

> Reuse fieldvalues computed while sorting at writing in ExportWriter
> ---
>
> Key: SOLR-12572
> URL: https://issues.apache.org/jira/browse/SOLR-12572
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch, 
> SOLR-12572.patch, SOLR-12572.patch, SOLR-12572.patch, slowness.patch
>
>
> While exporting result through "/export" handler,
> {code:java}
> http://localhost:8983/solr/core_name/export?q=my-query=severity+desc,timestamp+desc=severity,timestamp,msg
> {code}
> Doc-values are sought for all the {{sort}} fields defined (in this example 
> 'severity, 'timestamp'). When we stream out docs we again make doc-value 
> seeks against the {{fl}} fields ('severity','timestamp','msg') . 
> In most common use-cases we have {{fl = sort}} fields, or atleast the sort 
> fields are subset of {{fl}} fields, so if we can *pre-collect* the values 
> while sorting it, we can reduce the doc-value seeks potentially bringing 
> *speed improvement*.



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

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

[jira] [Commented] (LUCENE-8440) Add support for indexing and searching Line and Point shapes using LatLonShape encoding

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8440:
--

+1 to the patch

> Add support for indexing and searching Line and Point shapes using 
> LatLonShape encoding
> ---
>
> Key: LUCENE-8440
> URL: https://issues.apache.org/jira/browse/LUCENE-8440
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8440.patch, LUCENE-8440.patch
>
>
> This feature adds support to {{LatLonShape}} for indexing {{Line}} and 
> {{latitude, longitude}} Point types using the 6 dimension Triangle encoding 
> in {{LatLonShape}}. Indexed points and lines will be searchable using 
> {{LatLonShapeBoundingBoxQuery}} and the new {{LatLonShapePolygonQuery}} in 
> LUCENE-8435.



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

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

[jira] [Commented] (LUCENE-8440) Add support for indexing and searching Line and Point shapes using LatLonShape encoding

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-8440:


If there's no opposition I'll plan to commit the latest patch to sandbox 
tomorrow to get CI testing on it and continue iterating .

> Add support for indexing and searching Line and Point shapes using 
> LatLonShape encoding
> ---
>
> Key: LUCENE-8440
> URL: https://issues.apache.org/jira/browse/LUCENE-8440
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Priority: Major
> Attachments: LUCENE-8440.patch, LUCENE-8440.patch
>
>
> This feature adds support to {{LatLonShape}} for indexing {{Line}} and 
> {{latitude, longitude}} Point types using the 6 dimension Triangle encoding 
> in {{LatLonShape}}. Indexed points and lines will be searchable using 
> {{LatLonShapeBoundingBoxQuery}} and the new {{LatLonShapePolygonQuery}} in 
> LUCENE-8435.



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

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

[jira] [Resolved] (SOLR-12509) Improve SplitShardCmd performance and reliability

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-12509.
--
Resolution: Fixed

> Improve SplitShardCmd performance and reliability
> -
>
> Key: SOLR-12509
> URL: https://issues.apache.org/jira/browse/SOLR-12509
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12509.patch, SOLR-12509.patch
>
>
> {{SplitShardCmd}} is currently quite complex.
> Shard splitting occurs on active shards, which are still being updated, so 
> the splitting has to involve several carefully orchestrated steps, making 
> sure that new sub-shard placeholders are properly created and visible, and 
> then also applying buffered updates to the split leaders and performing 
> recovery on sub-shard replicas.
> This process could be simplified in cases where collections are not actively 
> being updated or can tolerate a little downtime - we could put the shard 
> "offline", ie. disable writing while the splitting is in progress (in order 
> to avoid users' confusion we should disable writing to the whole collection).
> The actual index splitting could perhaps be improved to use 
> {{HardLinkCopyDirectoryWrapper}} for creating a copy of the index by 
> hard-linking existing index segments, and then applying deletes to the 
> documents that don't belong in a sub-shard. However, the resulting index 
> slices that replicas would have to pull would be the same size as the whole 
> shard.



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

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

[jira] [Commented] (SOLR-12509) Improve SplitShardCmd performance and reliability

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12509:


Commit b5ed6350a0ea444553242ef2b141161c0fc3830b in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b5ed635 ]

SOLR-12509: Fix a bug when using round-robin doc assignment.


> Improve SplitShardCmd performance and reliability
> -
>
> Key: SOLR-12509
> URL: https://issues.apache.org/jira/browse/SOLR-12509
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12509.patch, SOLR-12509.patch
>
>
> {{SplitShardCmd}} is currently quite complex.
> Shard splitting occurs on active shards, which are still being updated, so 
> the splitting has to involve several carefully orchestrated steps, making 
> sure that new sub-shard placeholders are properly created and visible, and 
> then also applying buffered updates to the split leaders and performing 
> recovery on sub-shard replicas.
> This process could be simplified in cases where collections are not actively 
> being updated or can tolerate a little downtime - we could put the shard 
> "offline", ie. disable writing while the splitting is in progress (in order 
> to avoid users' confusion we should disable writing to the whole collection).
> The actual index splitting could perhaps be improved to use 
> {{HardLinkCopyDirectoryWrapper}} for creating a copy of the index by 
> hard-linking existing index segments, and then applying deletes to the 
> documents that don't belong in a sub-shard. However, the resulting index 
> slices that replicas would have to pull would be the same size as the whole 
> shard.



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

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 600c15d14e73274d4152e8ef1b8c0d0aae69fd18

[repro] Repro line:  ant test  -Dtestcase=TestWithCollection 
-Dtests.method=testDeleteWithCollection -Dtests.seed=D357DA1506E97CE4 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-PY 
-Dtests.timezone=Etc/GMT0 -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=LIRRollingUpdatesTest 
-Dtests.method=testNewLeaderAndMixedReplicas -Dtests.seed=D357DA1506E97CE4 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-ES 
-Dtests.timezone=Antarctica/Troll -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ChaosMonkeyNothingIsSafeTest 
-Dtests.method=test -Dtests.seed=D357DA1506E97CE4 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=sv -Dtests.timezone=Africa/Timbuktu 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ChaosMonkeyNothingIsSafeTest 
-Dtests.seed=D357DA1506E97CE4 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sv -Dtests.timezone=Africa/Timbuktu -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=MoveReplicaHDFSTest 
-Dtests.method=testFailedMove -Dtests.seed=D357DA1506E97CE4 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ga-IE 
-Dtests.timezone=Asia/Tokyo -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestCloudCollectionsListeners 
-Dtests.method=testSimpleCloudCollectionsListener -Dtests.seed=1AF69AC1B6A7C150 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ga 
-Dtests.timezone=America/Toronto -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestCloudCollectionsListeners 
-Dtests.method=testCollectionDeletion -Dtests.seed=1AF69AC1B6A7C150 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ga 
-Dtests.timezone=America/Toronto -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: 
d1173b8adc2aaf88582c84e964e2c35c783e0ca8
[repro] git fetch
[repro] git checkout 600c15d14e73274d4152e8ef1b8c0d0aae69fd18

[...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]   LIRRollingUpdatesTest
[repro]   ChaosMonkeyNothingIsSafeTest
[repro]   TestWithCollection
[repro]   MoveReplicaHDFSTest
[repro]solr/solrj
[repro]   TestCloudCollectionsListeners
[repro] ant compile-test

[...truncated 3334 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 
-Dtests.class="*.LIRRollingUpdatesTest|*.ChaosMonkeyNothingIsSafeTest|*.TestWithCollection|*.MoveReplicaHDFSTest"
 -Dtests.showOutput=onerror  -Dtests.seed=D357DA1506E97CE4 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=es-ES -Dtests.timezone=Antarctica/Troll 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] ant compile-test

[...truncated 448 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestCloudCollectionsListeners" -Dtests.showOutput=onerror  
-Dtests.seed=1AF69AC1B6A7C150 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=ga -Dtests.timezone=America/Toronto -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 78 lines...]
[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.LIRRollingUpdatesTest
[repro]   0/5 failed: org.apache.solr.cloud.MoveReplicaHDFSTest
[repro]   0/5 failed: org.apache.solr.cloud.TestWithCollection
[repro]   0/5 failed: org.apache.solr.common.cloud.TestCloudCollectionsListeners
[repro]   1/5 failed: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest
[repro] git checkout d1173b8adc2aaf88582c84e964e2c35c783e0ca8

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

G1GC collector warning on JavaBugs page

[Erick Erickson]

There's still the very firm warning _not_ to use the G1GC collector,
and a link to https://bugs.openjdk.java.net/browse/JDK-8038348 which
is marked as fixed "7u25, 8, 9". Should we remove that warning at this
point?

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

[jira] [Commented] (SOLR-12509) Improve SplitShardCmd performance and reliability

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12509:


Commit 724a65a60ab7537ab9f0c49cf0a93d2504553ae1 in lucene-solr's branch 
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=724a65a ]

SOLR-12509: Fix a bug when using round-robin doc assignment.


> Improve SplitShardCmd performance and reliability
> -
>
> Key: SOLR-12509
> URL: https://issues.apache.org/jira/browse/SOLR-12509
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12509.patch, SOLR-12509.patch
>
>
> {{SplitShardCmd}} is currently quite complex.
> Shard splitting occurs on active shards, which are still being updated, so 
> the splitting has to involve several carefully orchestrated steps, making 
> sure that new sub-shard placeholders are properly created and visible, and 
> then also applying buffered updates to the split leaders and performing 
> recovery on sub-shard replicas.
> This process could be simplified in cases where collections are not actively 
> being updated or can tolerate a little downtime - we could put the shard 
> "offline", ie. disable writing while the splitting is in progress (in order 
> to avoid users' confusion we should disable writing to the whole collection).
> The actual index splitting could perhaps be improved to use 
> {{HardLinkCopyDirectoryWrapper}} for creating a copy of the index by 
> hard-linking existing index segments, and then applying deletes to the 
> documents that don't belong in a sub-shard. However, the resulting index 
> slices that replicas would have to pull would be the same size as the whole 
> shard.



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost

Error Message:
org.apache.solr.common.SolrException: 

Stack Trace:
org.apache.solr.common.SolrException: org.apache.solr.common.SolrException: 
at 
__randomizedtesting.SeedInfo.seed([8CE06DE96FE2458F:33F5A317EC082009]:0)
at 
org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:78)
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
at 
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.printState(ComputePlanActionTest.java:151)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.solr.common.SolrException: 
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:300)
at 

[jira] [Reopened] (SOLR-12509) Improve SplitShardCmd performance and reliability

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  reopened SOLR-12509:
--

Thanks [~steve_rowe] - I found the bug (a side-effect of refactoring that 
somehow didn't affect tests on master), fix is coming.

> Improve SplitShardCmd performance and reliability
> -
>
> Key: SOLR-12509
> URL: https://issues.apache.org/jira/browse/SOLR-12509
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12509.patch, SOLR-12509.patch
>
>
> {{SplitShardCmd}} is currently quite complex.
> Shard splitting occurs on active shards, which are still being updated, so 
> the splitting has to involve several carefully orchestrated steps, making 
> sure that new sub-shard placeholders are properly created and visible, and 
> then also applying buffered updates to the split leaders and performing 
> recovery on sub-shard replicas.
> This process could be simplified in cases where collections are not actively 
> being updated or can tolerate a little downtime - we could put the shard 
> "offline", ie. disable writing while the splitting is in progress (in order 
> to avoid users' confusion we should disable writing to the whole collection).
> The actual index splitting could perhaps be improved to use 
> {{HardLinkCopyDirectoryWrapper}} for creating a copy of the index by 
> hard-linking existing index segments, and then applying deletes to the 
> documents that don't belong in a sub-shard. However, the resulting index 
> slices that replicas would have to pull would be the same size as the whole 
> shard.



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

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 22994 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: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of 
sequence: expected level 2, got level 3
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of 
sequence: expected level 2, got level 3
 [java] Processed 2252 links (1804 relative) to 3147 anchors in 247 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 = 

Re: Keeping RefGuide screenshots up to date

[Shawn Heisey]

On 8/2/2018 8:16 AM, Cassandra Targett wrote:
> My feeling is we should update all of them, especially if the change
> you're talking about isn't made until 8 - a major version feels like a
> good time to refresh all the screenshots as there have been enough
> smaller CSS changes in 7.x that make them obsolete in many other ways.

+1 to update all screenshots in the 8.0 reference guide.

That way we can be absolutely sure that what a user sees in the
documentation will not be different than what they see on their own
screen.  This is a very fast-moving project, so it is easy for info in
the docs to get out of date.

Here's an interesting extension:

https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbknoalclacl?hl=en

For screens where all the information fits without scrolling, it would
be nice to specify uniform window sizes.

Thanks,
Shawn


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

[jira] [Resolved] (SOLR-12594) MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-12594.
--
Resolution: Fixed

> MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen
> ---
>
> Key: SOLR-12594
> URL: https://issues.apache.org/jira/browse/SOLR-12594
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
>
> as reported on the user list...
> {quote}
> We encounter a lot of log warning entries from the MetricsHistoryHandler 
> saying
> o.a.s.h.a.MetricsHistoryHandler Unknown format of leader id, skipping:
> 244550997187166214-server1-b.myhost:8983_solr-n_94
> I don't even know what this _MetricsHistoryHandler_ does, but at least 
> there's a warning.
> Looking at the code you can see that it has to fail if the hostname of the 
> node contains a hyphen:
> {quote}
> {code}
> String[] ids = oid.split("-");
> if (ids.length != 3) { // unknown format
>   log.warn("Unknown format of leader id, skipping: " + oid);
>   return null;
> }
> {code}



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

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

[jira] [Commented] (SOLR-12594) MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12594:


Commit b03c1ad6f6ccf5a90a221d667152946f5c3dead3 in lucene-solr's branch 
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b03c1ad ]

SOLR-12594: MetricsHistoryHandler.getOverseerLeader fails when hostname 
contains hyphen.


> MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen
> ---
>
> Key: SOLR-12594
> URL: https://issues.apache.org/jira/browse/SOLR-12594
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
>
> as reported on the user list...
> {quote}
> We encounter a lot of log warning entries from the MetricsHistoryHandler 
> saying
> o.a.s.h.a.MetricsHistoryHandler Unknown format of leader id, skipping:
> 244550997187166214-server1-b.myhost:8983_solr-n_94
> I don't even know what this _MetricsHistoryHandler_ does, but at least 
> there's a warning.
> Looking at the code you can see that it has to fail if the hostname of the 
> node contains a hyphen:
> {quote}
> {code}
> String[] ids = oid.split("-");
> if (ids.length != 3) { // unknown format
>   log.warn("Unknown format of leader id, skipping: " + oid);
>   return null;
> }
> {code}



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

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

[jira] [Commented] (SOLR-12590) Improve Solr resource loader coverage in the ref guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-12590:
--

Oh, also, FYI, the patch doesn't apply anymore after the changes committed with 
SOLR-11870.

> Improve Solr resource loader coverage in the ref guide
> --
>
> Key: SOLR-12590
> URL: https://issues.apache.org/jira/browse/SOLR-12590
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12590.patch
>
>
> In SolrCloud, storing large resources (e.g. binary machine learned models) on 
> the local filesystem should be a viable alternative to increasing ZooKeeper's 
> max file size limit (1MB), but there are undocumented complications.



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

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

[jira] [Resolved] (LUCENE-8418) LatLonShapeBoundingBoxQuery failure in Polygon with Hole

[Nicholas Knize (JIRA)]

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

Nicholas Knize resolved LUCENE-8418.

Resolution: Fixed

> LatLonShapeBoundingBoxQuery failure in Polygon with Hole
> 
>
> Key: LUCENE-8418
> URL: https://issues.apache.org/jira/browse/LUCENE-8418
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Major
>
> Found the following test failure while testing with a random polygon with 
> hole:
> {code}
> 07:13:46[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLatLonShape -Dtests.method=testBasicIntersects 
> -Dtests.seed=A8704FF5E1106095 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=ar -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
> 07:13:46[junit4] FAILURE 0.48s J0 | TestLatLonShape.testBasicIntersects 
> <<<
> 07:13:46[junit4]> Throwable #1: java.lang.AssertionError: 
> expected:<0> but was:<1>
> 07:13:46[junit4]> at 
> __randomizedtesting.SeedInfo.seed([A8704FF5E1106095:9F0DBC00DD87C3EB]:0)
> 07:13:46[junit4]> at 
> org.apache.lucene.document.TestLatLonShape.testBasicIntersects(TestLatLonShape.java:113)
> 07:13:46[junit4]> at java.lang.Thread.run(Thread.java:748)
> 07:13:46[junit4]   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/workspace/apache+lucene-solr+branch_7x/lucene/build/sandbox/test/J0/temp/lucene.document.TestLatLonShape_A8704FF5E1106095-001
> 07:13:46[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {}, docValues:{}, maxPointsInLeafNode=140, maxMBSortInHeap=7.774833175701376, 
> sim=RandomSimilarity(queryNorm=false): {}, locale=ar, 
> timezone=Europe/Amsterdam
> 07:13:46[junit4]   2> NOTE: Linux 3.16.0-4-amd64 amd64/Oracle Corporation 
> 1.8.0_171 (64-bit)/cpus=16,threads=1,free=302653784,total=449314816
> 07:13:46[junit4]   2> NOTE: All tests run in this JVM: [TestLatLonShape]
> 07:13:46[junit4] Completed [18/24 (1!)] on J0 in 21.09s, 3 tests, 1 
> failure, 1 skipped <<< FAILURES!
> {code}



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

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

[jira] [Commented] (SOLR-12594) MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12594:


Commit d1173b8adc2aaf88582c84e964e2c35c783e0ca8 in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d1173b8 ]

SOLR-12594: MetricsHistoryHandler.getOverseerLeader fails when hostname 
contains hyphen.


> MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen
> ---
>
> Key: SOLR-12594
> URL: https://issues.apache.org/jira/browse/SOLR-12594
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
>
> as reported on the user list...
> {quote}
> We encounter a lot of log warning entries from the MetricsHistoryHandler 
> saying
> o.a.s.h.a.MetricsHistoryHandler Unknown format of leader id, skipping:
> 244550997187166214-server1-b.myhost:8983_solr-n_94
> I don't even know what this _MetricsHistoryHandler_ does, but at least 
> there's a warning.
> Looking at the code you can see that it has to fail if the hostname of the 
> node contains a hyphen:
> {quote}
> {code}
> String[] ids = oid.split("-");
> if (ids.length != 3) { // unknown format
>   log.warn("Unknown format of leader id, skipping: " + oid);
>   return null;
> }
> {code}



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

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

[jira] [Commented] (SOLR-12611) Add version information to thread dump

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12611:
-

New patch that does the wait() in a truly endless loop.  Before starting the 
thread, daemon is enabled.  Testing (on Windows 7) indicates that the JVM stops 
immediately, doesn't need to be hard-killed.  CHANGES.txt addition also present.

> Add version information to thread dump
> --
>
> Key: SOLR-12611
> URL: https://issues.apache.org/jira/browse/SOLR-12611
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.4
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: SOLR-12611.patch, SOLR-12611.patch
>
>
> Thread dumps contain stacktrace info.  Without knowing the Solr version, it 
> can be difficult to compare stacktraces to source code.
> If exact version information is available in the thread dump, it will be 
> possible to look at source code to understand stacktrace information.  If 
> *full* version information is present, then it would even be possible to 
> learn whether the user is running an official binary build or if they have 
> built Solr themselves.



--
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-12611) Add version information to thread dump

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-12611:

Attachment: SOLR-12611.patch

> Add version information to thread dump
> --
>
> Key: SOLR-12611
> URL: https://issues.apache.org/jira/browse/SOLR-12611
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.4
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: SOLR-12611.patch, SOLR-12611.patch
>
>
> Thread dumps contain stacktrace info.  Without knowing the Solr version, it 
> can be difficult to compare stacktraces to source code.
> If exact version information is available in the thread dump, it will be 
> possible to look at source code to understand stacktrace information.  If 
> *full* version information is present, then it would even be possible to 
> learn whether the user is running an official binary build or if they have 
> built Solr themselves.



--
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-12485) Xml loader should save the relationship of children

[mosh (JIRA)]

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

mosh commented on SOLR-12485:
-

Hey,
just opened a pull request with a basic test which adds labelled children in an 
xml document.

> Xml loader should save the relationship of children
> ---
>
> Key: SOLR-12485
> URL: https://issues.apache.org/jira/browse/SOLR-12485
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Once SolrInputDocument supports labeled child documents, XmlLoader should add 
> the child document to the map while saving its key name, to maintain the 
> child's relationship to its parent.



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

[GitHub] lucene-solr pull request #430: SOLR-12485: support labelled children in xml ...

[moshebla]

GitHub user moshebla opened a pull request:

https://github.com/apache/lucene-solr/pull/430

SOLR-12485: support labelled children in xml documents



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/moshebla/lucene-solr SOLR-12485

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/430.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #430


commit 494bc0c1ec9ee6a588afaf16dbdc80c89c62355a
Author: Moshe 
Date:   2018-08-02T16:03:13Z

SOLR-12485: support labelled children in xml documents




---

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

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

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Error from server at http://127.0.0.1:36043/_ygc: 
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /autoscaling.json

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36043/_ygc: 
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /autoscaling.json
at 
__randomizedtesting.SeedInfo.seed([D357DA1506E97CE4:5B03E5CFA815111C]: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.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:416)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:341)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1006)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
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 

[jira] [Commented] (SOLR-12611) Add version information to thread dump

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-12611:


bq. I wanted to make sure that the loop can exit quickly when the run flag goes 
false.

It should be flag + long sleep + interrupt to recheck the condition.

> Add version information to thread dump
> --
>
> Key: SOLR-12611
> URL: https://issues.apache.org/jira/browse/SOLR-12611
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.4
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: SOLR-12611.patch
>
>
> Thread dumps contain stacktrace info.  Without knowing the Solr version, it 
> can be difficult to compare stacktraces to source code.
> If exact version information is available in the thread dump, it will be 
> possible to look at source code to understand stacktrace information.  If 
> *full* version information is present, then it would even be possible to 
> learn whether the user is running an official binary build or if they have 
> built Solr themselves.



--
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-12509) Improve SplitShardCmd performance and reliability

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12509:
---

Reproducing {{SolrIndexSplitterTest.testSplitAlternatelyLink()}} failure, from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2469/]:

{noformat}
Checking out Revision 600c15d14e73274d4152e8ef1b8c0d0aae69fd18 
(refs/remotes/origin/branch_7x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=SolrIndexSplitterTest -Dtests.method=testSplitAlternatelyLink 
-Dtests.seed=2EC831F1D9B21D7D -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=pl -Dtests.timezone=CTT -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 1.02s J1 | SolrIndexSplitterTest.testSplitAlternatelyLink 
<<<
   [junit4]> Throwable #1: java.lang.AssertionError: split index1 has wrong 
number of documents expected:<5> but was:<6>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([2EC831F1D9B21D7D:9992FDD95CED0639]:0)
   [junit4]>at 
org.apache.solr.update.SolrIndexSplitterTest.doTestSplitAlternately(SolrIndexSplitterTest.java:272)
   [junit4]>at 
org.apache.solr.update.SolrIndexSplitterTest.testSplitAlternatelyLink(SolrIndexSplitterTest.java:247)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{id=PostingsFormat(name=Memory)}, 
docValues:{_version_=DocValuesFormat(name=Lucene70), 
id=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=419, 
maxMBSortInHeap=6.5586874621200195, sim=RandomSimilarity(queryNorm=false): {}, 
locale=pl, timezone=CTT
   [junit4]   2> NOTE: Linux 4.15.0-29-generic amd64/Oracle Corporation 
1.8.0_172 (64-bit)/cpus=8,threads=1,free=160622208,total=536870912
{noformat}

> Improve SplitShardCmd performance and reliability
> -
>
> Key: SOLR-12509
> URL: https://issues.apache.org/jira/browse/SOLR-12509
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12509.patch, SOLR-12509.patch
>
>
> {{SplitShardCmd}} is currently quite complex.
> Shard splitting occurs on active shards, which are still being updated, so 
> the splitting has to involve several carefully orchestrated steps, making 
> sure that new sub-shard placeholders are properly created and visible, and 
> then also applying buffered updates to the split leaders and performing 
> recovery on sub-shard replicas.
> This process could be simplified in cases where collections are not actively 
> being updated or can tolerate a little downtime - we could put the shard 
> "offline", ie. disable writing while the splitting is in progress (in order 
> to avoid users' confusion we should disable writing to the whole collection).
> The actual index splitting could perhaps be improved to use 
> {{HardLinkCopyDirectoryWrapper}} for creating a copy of the index by 
> hard-linking existing index segments, and then applying deletes to the 
> documents that don't belong in a sub-shard. However, the resulting index 
> slices that replicas would have to pull would be the same size as the whole 
> shard.



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

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

[jira] [Commented] (SOLR-12611) Add version information to thread dump

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12611:
-

The reason that the sleep was so short in my alternate code was because I 
wanted to make sure that the loop can exit quickly when the run flag goes false.

My overall knowledge did not include information like daemon threads.  After 
looking that up, it sounds like a great idea, and simplifies the code.  Thanks 
for the info!

My motivation here is from the perspective of helping people with Solr 
problems.  I've seen situations where users do think of sending a stacktrace, 
but do not mention which version of Solr they're running.  Asking for missing 
information can mean a long delay in figuring out the problem.

> Add version information to thread dump
> --
>
> Key: SOLR-12611
> URL: https://issues.apache.org/jira/browse/SOLR-12611
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.4
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: SOLR-12611.patch
>
>
> Thread dumps contain stacktrace info.  Without knowing the Solr version, it 
> can be difficult to compare stacktraces to source code.
> If exact version information is available in the thread dump, it will be 
> possible to look at source code to understand stacktrace information.  If 
> *full* version information is present, then it would even be possible to 
> learn whether the user is running an official binary build or if they have 
> built Solr themselves.



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+24) - Build # 22583 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22583/
Java: 64bit/jdk-11-ea+24 -XX:+UseCompressedOops -XX:+UseSerialGC

11 tests failed.
FAILED:  
org.apache.solr.metrics.reporters.solr.SolrCloudReportersTest.testExplicitConfiguration

Error Message:
Expected test_collection with 2 shards and 2 replicas null Live Nodes: 
[127.0.0.1:32817_solr, 127.0.0.1:33097_solr] Last available state: null

Stack Trace:
java.lang.AssertionError: Expected test_collection with 2 shards and 2 replicas
null
Live Nodes: [127.0.0.1:32817_solr, 127.0.0.1:33097_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([3269784C9B939560:76A558B7F5A9430A]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:278)
at 
org.apache.solr.metrics.reporters.solr.SolrCloudReportersTest.testExplicitConfiguration(SolrCloudReportersTest.java:70)
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:566)
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 

[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....

[barrotsteindev]

Github user barrotsteindev commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/428#discussion_r207252080
  
--- Diff: 
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
 ---
@@ -144,15 +153,19 @@ public void init(NamedList args) {
 }
 
 Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
 if (null != defaultTimeZoneParam) {
-  defaultTimeZone = 
DateTimeZone.forID(defaultTimeZoneParam.toString());
+  TimeZone.getTimeZone(defaultTimeZoneParam.toString());
+  defaultTimeZone = ZoneId.of(defaultTimeZoneParam.toString());
 }
 
 Collection formatsParam = args.removeConfigArgs(FORMATS_PARAM);
 if (null != formatsParam) {
   for (String value : formatsParam) {
-formats.put(value, 
DateTimeFormat.forPattern(value).withZone(defaultTimeZone).withLocale(locale));
+DateTimeFormatter formatter = new 
DateTimeFormatterBuilder().parseCaseInsensitive()
--- End diff --

I will have another look at the joda time defaults to double check 


---

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

[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....

[barrotsteindev]

Github user barrotsteindev commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/428#discussion_r207251678
  
--- Diff: 
solr/core/src/test-files/solr/collection1/conf/solrconfig-parsing-update-processor-chains.xml
 ---
@@ -29,43 +29,43 @@
 
   
 
-  -MM-dd'T'HH:mm:ss.SSSZ
--- End diff --

Yes sadly there is no backwards compatibility between the two. For example 
a single Z and 5 Z in the format have a different meaning. This is all 
explained here:   

https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html


---

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

[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/428#discussion_r207052167
  
--- Diff: 
solr/core/src/test-files/solr/collection1/conf/solrconfig-parsing-update-processor-chains.xml
 ---
@@ -29,43 +29,43 @@
 
   
 
-  -MM-dd'T'HH:mm:ss.SSSZ
--- End diff --

Can you explain why you made this and other changes in this file?  If the 
format is compatible (joda -> java.text) then no changes would be necessary 
here.  But if there's a backwards incompatibility here then, alas, we'll need 
to let users know about... 


---

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

[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/428#discussion_r207048145
  
--- Diff: 
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
 ---
@@ -144,15 +153,19 @@ public void init(NamedList args) {
 }
 
 Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
 if (null != defaultTimeZoneParam) {
-  defaultTimeZone = 
DateTimeZone.forID(defaultTimeZoneParam.toString());
+  TimeZone.getTimeZone(defaultTimeZoneParam.toString());
--- End diff --

This line seems to be needless, since you do nothing with the response?  
And it's the obsolete TimeZone class (we want ZoneId).


---

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

[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/428#discussion_r207049175
  
--- Diff: 
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
 ---
@@ -144,15 +153,19 @@ public void init(NamedList args) {
 }
 
 Object defaultTimeZoneParam = args.remove(DEFAULT_TIME_ZONE_PARAM);
-DateTimeZone defaultTimeZone = DateTimeZone.UTC;
+ZoneId defaultTimeZone = ZoneOffset.UTC;
 if (null != defaultTimeZoneParam) {
-  defaultTimeZone = 
DateTimeZone.forID(defaultTimeZoneParam.toString());
+  TimeZone.getTimeZone(defaultTimeZoneParam.toString());
+  defaultTimeZone = ZoneId.of(defaultTimeZoneParam.toString());
 }
 
 Collection formatsParam = args.removeConfigArgs(FORMATS_PARAM);
 if (null != formatsParam) {
   for (String value : formatsParam) {
-formats.put(value, 
DateTimeFormat.forPattern(value).withZone(defaultTimeZone).withLocale(locale));
+DateTimeFormatter formatter = new 
DateTimeFormatterBuilder().parseCaseInsensitive()
--- End diff --

it'd be nice if case insensitivity & leniency could somehow be configured 
in the pattern (which it can't AFAIK), or failing that then new options to set 
these things on all patterns conditionally (similar to how we have a default 
time zone).  But that need not be addressed now; it can be added in SOLR-12591. 
 Did you attempt feature parity here (thus presumably Joda was by default case 
insensitive, and leniency=false)?


---

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

[GitHub] lucene-solr pull request #428: SOLR-12586: deprecate joda-time and use java....

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/428#discussion_r207051620
  
--- Diff: 
solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
 ---
@@ -115,9 +123,10 @@ protected Object mutateValue(Object srcVal) {
   for (Map.Entry format : 
formats.entrySet()) {
 DateTimeFormatter parser = format.getValue();
 try {
-  DateTime dateTime = parser.parseDateTime(srcStringVal);
-  return dateTime.withZone(DateTimeZone.UTC).toDate();
-} catch (IllegalArgumentException e) {
+  TemporalAccessor parsedTemporalDate = 
parser.parseBest(srcStringVal, OffsetDateTime::from,
--- End diff --

Shouldn't this be ordered most specific to least specific?  Thus Instant 
comes first.
Or alternatively, parse to get a temporal accessor, then query to see what 
elements of the time are there and not there and build an Instant accordingly.  
My most recent patch in https://issues.apache.org/jira/browse/SOLR-12561 shows 
this approach.  I think this is more efficient since internally there is no 
exception.  Though perhaps it's less obvious / understandable.  Shrug; I wonder 
what you think.


---

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

[jira] [Comment Edited] (SOLR-12586) Replace use of Joda Time with Java 8 java.time

[Bar Rotstein (JIRA)]

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

Bar Rotstein edited comment on SOLR-12586 at 8/2/18 2:29 PM:
-

I changed the zoneOffset to UTC in configset. Hopefully that was the only 
blocker.


was (Author: brot):
I changed the zoneOffset to use UTC in configset. Hopefully that was the only 
blocker.

> Replace use of Joda Time with Java 8 java.time
> --
>
> Key: SOLR-12586
> URL: https://issues.apache.org/jira/browse/SOLR-12586
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Minor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We're using Joda Time, a dependency in a couple places.  Now that we are on 
> Java 8, we ought to drop the dependency, using the equivalent java.time 
> package instead.  As I understand it, Joda time more or less was incorporated 
> to Java as java.time with some fairly minor differences.
> Usages:
>  * ConfigSetService
>  * ParseDateFieldUpdateProcessorFactory
> And some related tests.



--
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-12586) Replace use of Joda Time with Java 8 java.time

[Bar Rotstein (JIRA)]

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

Bar Rotstein commented on SOLR-12586:
-

I changed the zoneOffset to use UTC in configset. Hopefully that was the only 
blocker.

> Replace use of Joda Time with Java 8 java.time
> --
>
> Key: SOLR-12586
> URL: https://issues.apache.org/jira/browse/SOLR-12586
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Minor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We're using Joda Time, a dependency in a couple places.  Now that we are on 
> Java 8, we ought to drop the dependency, using the equivalent java.time 
> package instead.  As I understand it, Joda time more or less was incorporated 
> to Java as java.time with some fairly minor differences.
> Usages:
>  * ConfigSetService
>  * ParseDateFieldUpdateProcessorFactory
> And some related tests.



--
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: Keeping RefGuide screenshots up to date

[Cassandra Targett]

My feeling is we should update all of them, especially if the change you're
talking about isn't made until 8 - a major version feels like a good time
to refresh all the screenshots as there have been enough smaller CSS
changes in 7.x that make them obsolete in many other ways.

IMO, all of them should have also been updated when the Suggestions menu
tab was also added and I've done some as I have time since that was added.

I'm not saying YOU should do all of them, though. I think it would be
enough to do whatever you have time to do  now, and file an issue to update
all the screenshots before the 8.0 Guide is done. Maybe some volunteers
will help make it short work, but I'll probably just end up doing all of
them when the time comes.

Selenium might be fine - I've used it only in a proof of concept like 8
years ago for screenshots, so I don't have a great sense for what it's like
to use longer term. If you want to try that, some automated UI testing
would be great.

The Asciidoctor project also has a plugin to automate getting screenshots (
https://github.com/asciidoctor/asciidoctorj-screenshot), but I only know
about it from hearing of it, I've never tried to use it. It seems geared
toward public websites, whereas Selenium probably has more fine-grained
control.

On Thu, Aug 2, 2018 at 5:37 AM Jan Høydahl  wrote:

> In SOLR-12613 we'll rename the "Cloud" menu in Admin UI to "Cluster". This
> affects pretty much
> all admin UI screenshots in the Reference Guide, so the next question then
> is "How do we
> keep all those screenshots up to date?". I counted a total of 42 screen
> shots of the UI, many
> which require creating collections, adding data, typing things into the UI
> etc up front.
>
> Due to the work involved, we often tend to update only a few shots and
> leave others as-is even
> if they are inaccurate. Example is the new "Suggestions" menu tab - there
> are 27 screen
> shots in the ref guide which are not updated with that menu option.
>
> For SOLR-12613 I'm tempted to only update the four images in
> "cloud-screens" folder for now.
>
> Perhaps for the future an automated approach can be taken using Selenium,
> as outlined in
> this post:
> https://blog.codeship.com/automating-screenshots-in-documentation/ This
> could
> in first phase be a standalone tool to generate screenshots but could also
> be extended with
> other tests to get some validation of the UI itself, which is completely
> lacking today. WDYT?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> 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

[JIRA]

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

Jan Høydahl commented on SOLR-8207:
---

Question regarding JavaScript / ECMAscript version we can use in Admin UI. My 
IntelliJ barfs on this "arrow" syntax (in {{cloud.js}}) when configured with 
ECMAscript 5.1:
{code:java}
filteredNodes = node_keys.filter(nod => nod.indexOf($scope.nodeFilter) !== 
-1);{code}
If I change to ECMAscript6, then it validates OK. ES6 came in 2015 and is 
supported by modern browsers. So do we have any policies on what version we 
MUST stick to in the Admin UI?

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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: Keeping RefGuide screenshots up to date

[Alexandre Rafalovitch]

+1 as I think it would open up other example/documentation options.

Chrome driver by itself may be sufficient for just sample screenshots,
but Selenium may be better for testing and more advanced use-cases.
Neither though I think will get a collection into the correct
pre-populated state. So that would still need to be figured out (maybe
something like Postman: https://www.getpostman.com/postman ).

I think it would also go hand-in-hand with improving examples, so the
screenshots are taken of something users could also use/reproduce.
And/or with longer "getting started" example that could be automated
with screenshots along the way.

Regards,
   Alex.

On 2 August 2018 at 06:37, Jan Høydahl  wrote:
> In SOLR-12613 we'll rename the "Cloud" menu in Admin UI to "Cluster". This 
> affects pretty much
> all admin UI screenshots in the Reference Guide, so the next question then is 
> "How do we
> keep all those screenshots up to date?". I counted a total of 42 screen shots 
> of the UI, many
> which require creating collections, adding data, typing things into the UI 
> etc up front.
>
> Due to the work involved, we often tend to update only a few shots and leave 
> others as-is even
> if they are inaccurate. Example is the new "Suggestions" menu tab - there are 
> 27 screen
> shots in the ref guide which are not updated with that menu option.
>
> For SOLR-12613 I'm tempted to only update the four images in "cloud-screens" 
> folder for now.
>
> Perhaps for the future an automated approach can be taken using Selenium, as 
> outlined in
> this post: https://blog.codeship.com/automating-screenshots-in-documentation/ 
> This could
> in first phase be a standalone tool to generate screenshots but could also be 
> extended with
> other tests to get some validation of the UI itself, which is completely 
> lacking today. WDYT?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Closed] (SOLR-5332) Add "preserve original" setting to the EdgeNGramFilterFactory

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-5332.
---

> Add "preserve original" setting to the EdgeNGramFilterFactory
> -
>
> Key: SOLR-5332
> URL: https://issues.apache.org/jira/browse/SOLR-5332
> Project: Solr
>  Issue Type: Wish
>Affects Versions: 4.4, 4.5, 4.5.1, 4.6
>Reporter: Alexander S.
>Priority: Major
>
> Hi, as described here: 
> http://lucene.472066.n3.nabble.com/Help-to-figure-out-why-query-does-not-match-td4086967.html
>  the problem is in that if you have these 2 strings to index:
> 1. facebook.com/someuser.1
> 2. facebook.com/someveryandverylongusername
> and the edge ngram filter factory with min and max gram size settings 2 and 
> 25, search requests for these urls will fail.
> But search requests for:
> 1. facebook.com/someuser
> 2. facebook.com/someveryandverylonguserna
> will work properly.
> It's because first url has "1" at the end, which is lover than the allowed 
> min gram size. In the second url the user name is longer than the max gram 
> size (27 characters).
> Would be good to have a "preserve original" option, that will add the 
> original string to the index if it does not fit the allowed gram size, so 
> that "1" and "someveryandverylongusername" tokens will also be added to the 
> index.
> Best,
> Alex



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

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

[jira] [Resolved] (SOLR-5332) Add "preserve original" setting to the EdgeNGramFilterFactory

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch resolved SOLR-5332.
-
   Resolution: Implemented
Fix Version/s: (was: 6.0)
   (was: 5.2)

It seems most of this has been implemented in other, already referenced issues. 
It is not clear what is left to do here. 

I suggest a new issue is opened with latest needs, if any still exist in the 
current Solr version.

> Add "preserve original" setting to the EdgeNGramFilterFactory
> -
>
> Key: SOLR-5332
> URL: https://issues.apache.org/jira/browse/SOLR-5332
> Project: Solr
>  Issue Type: Wish
>Affects Versions: 4.4, 4.5, 4.5.1, 4.6
>Reporter: Alexander S.
>Priority: Major
>
> Hi, as described here: 
> http://lucene.472066.n3.nabble.com/Help-to-figure-out-why-query-does-not-match-td4086967.html
>  the problem is in that if you have these 2 strings to index:
> 1. facebook.com/someuser.1
> 2. facebook.com/someveryandverylongusername
> and the edge ngram filter factory with min and max gram size settings 2 and 
> 25, search requests for these urls will fail.
> But search requests for:
> 1. facebook.com/someuser
> 2. facebook.com/someveryandverylonguserna
> will work properly.
> It's because first url has "1" at the end, which is lover than the allowed 
> min gram size. In the second url the user name is longer than the max gram 
> size (27 characters).
> Would be good to have a "preserve original" option, that will add the 
> original string to the index if it does not fit the allowed gram size, so 
> that "1" and "someveryandverylongusername" tokens will also be added to the 
> index.
> Best,
> Alex



--
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] [Closed] (SOLR-5152) EdgeNGramFilterFactory deletes token

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-5152.
---

Has been resolved (duplicate) a while ago.

> EdgeNGramFilterFactory deletes token
> 
>
> Key: SOLR-5152
> URL: https://issues.apache.org/jira/browse/SOLR-5152
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Christoph Lingg
>Priority: Major
> Attachments: SOLR-5152-v5.0.0.patch, SOLR-5152.patch
>
>
> I am using EdgeNGramFilterFactory in my schema.xml
> {code:xml} positionIncrementGap="100">
>   
> 
>  maxGramSize="10" side="front" />
>   
> {code}
> Some tokens in my index only consist of one character, let's say {{R}}. 
> minGramSize is set to 2 and is bigger than the length of the token. I 
> expected the NGramFilter to left {{R}} unchanged but in fact it is deleting 
> the token.
> For my use case this interpretation is undesirable, and probably for most use 
> cases too!?



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

[JIRA]

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

Jan Høydahl commented on SOLR-8207:
---

New push to PR
 * Reverted to existing "Cloud" naming for the UI menu, after spinning that 
rename off in SOLR-12613
 * Removed more remnants of radial graph code
 * Fix a failing test and removed some logging and nocommit
 * Made "Graph" tab the default again (will be flipped in 8.0 by SOLR-12614)
 * Added Reference Guide screenshot and description for the new nodes screen
 * Merge in latest master
 * Precommit passes

The test suite fails of course :( but I cannot see any of the failures being 
related to this patch.

BTW: Here's a preview of the edits to RefGuide page "Cloud Screens" including 
the new screenshot: 
[https://github.com/cominvent/lucene-solr/blob/solr8207-ui-nodes-tab/solr/solr-ref-guide/src/cloud-screens.adoc]
 

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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

[jira] [Updated] (SOLR-12594) MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-12594:
-
Affects Version/s: 7.4

> MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen
> ---
>
> Key: SOLR-12594
> URL: https://issues.apache.org/jira/browse/SOLR-12594
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
>
> as reported on the user list...
> {quote}
> We encounter a lot of log warning entries from the MetricsHistoryHandler 
> saying
> o.a.s.h.a.MetricsHistoryHandler Unknown format of leader id, skipping:
> 244550997187166214-server1-b.myhost:8983_solr-n_94
> I don't even know what this _MetricsHistoryHandler_ does, but at least 
> there's a warning.
> Looking at the code you can see that it has to fail if the hostname of the 
> node contains a hyphen:
> {quote}
> {code}
> String[] ids = oid.split("-");
> if (ids.length != 3) { // unknown format
>   log.warn("Unknown format of leader id, skipping: " + oid);
>   return null;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12594) MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-12594:
-
Component/s: metrics

> MetricsHistoryHandler.getOverseerLeader fails when hostname contains hyphen
> ---
>
> Key: SOLR-12594
> URL: https://issues.apache.org/jira/browse/SOLR-12594
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
>
> as reported on the user list...
> {quote}
> We encounter a lot of log warning entries from the MetricsHistoryHandler 
> saying
> o.a.s.h.a.MetricsHistoryHandler Unknown format of leader id, skipping:
> 244550997187166214-server1-b.myhost:8983_solr-n_94
> I don't even know what this _MetricsHistoryHandler_ does, but at least 
> there's a warning.
> Looking at the code you can see that it has to fail if the hostname of the 
> node contains a hyphen:
> {quote}
> {code}
> String[] ids = oid.split("-");
> if (ids.length != 3) { // unknown format
>   log.warn("Unknown format of leader id, skipping: " + oid);
>   return null;
> }
> {code}



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

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

[jira] [Updated] (SOLR-12614) Make "Nodes" tab the default in AdminUI Cloud view

[JIRA]

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

Jan Høydahl updated SOLR-12614:
---
Attachment: SOLR-12614.patch

> Make "Nodes" tab the default in AdminUI Cloud view
> --
>
> Key: SOLR-12614
> URL: https://issues.apache.org/jira/browse/SOLR-12614
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12614.patch
>
>
> The Nodes tab was added in version 7.5, but "Graph" was still the default 
> tab. Make the new Nodes tab the default one when opening the "Cloud" view.



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

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.update.SolrIndexSplitterTest.testSplitAlternatelyLink

Error Message:
split index1 has wrong number of documents expected:<5> but was:<6>

Stack Trace:
java.lang.AssertionError: split index1 has wrong number of documents 
expected:<5> but was:<6>
at 
__randomizedtesting.SeedInfo.seed([2EC831F1D9B21D7D:9992FDD95CED0639]: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.apache.solr.update.SolrIndexSplitterTest.doTestSplitAlternately(SolrIndexSplitterTest.java:272)
at 
org.apache.solr.update.SolrIndexSplitterTest.testSplitAlternatelyLink(SolrIndexSplitterTest.java:247)
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 

[jira] [Commented] (SOLR-12344) SolrSlf4jReporter doesn't set MDC context

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12344:


Commit 32e417959a8098505812b87a275844f2cc98b1d1 in lucene-solr's branch 
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=32e4179 ]

SOLR-12344: SolrSlf4jReporter doesn't set MDC context.


> SolrSlf4jReporter doesn't set MDC context
> -
>
> Key: SOLR-12344
> URL: https://issues.apache.org/jira/browse/SOLR-12344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Varun Thacker
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12344.patch
>
>
> I setup a slf4j reporter like this on master
> solr.xml
> {code:java}
> 
>class="org.apache.solr.metrics.reporters.SolrSlf4jReporter">
> 1
> UPDATE./update.requestTimes
> update_logger
>   
> {code}
> log4j2.xml
> {code:java}
> 
> 
> 
>   
> 
>   
> 
>   %-4r [%t] %-5p %c %x [%X{collection} %X{shard} %X{replica} 
> %X{core}] %c; %m%n
> 
>   
> 
>  name="RollingFile"
> fileName="${sys:solr.log.dir}/solr.log"
> filePattern="${sys:solr.log.dir}/solr.log.%i" >
>   
> 
>   %-5p - %d{-MM-dd HH:mm:ss.SSS}; [%X{collection} %X{shard} 
> %X{replica} %X{core}] %c; %m%n
> 
>   
>   
> 
> 
>   
>   
> 
>  name="RollingMetricFile"
> fileName="${sys:solr.log.dir}/solr_metric.log"
> filePattern="${sys:solr.log.dir}/solr_metric.log.%i" >
>   
> 
>   %-5p - %d{-MM-dd HH:mm:ss.SSS}; [%X{collection} %X{shard} 
> %X{replica} %X{core}] %c; %m%n
> 
>   
>   
> 
> 
>   
>   
> 
>   
>   
> 
> 
> 
> 
>   
> 
> 
>   
>   
> 
>   
> 
> {code}
> The output I get from the solr_metric.log file is like this
> {code:java}
> INFO  - 2018-05-11 15:31:16.009; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds
> INFO  - 2018-05-11 15:31:17.010; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds
> INFO  - 2018-05-11 15:31:18.010; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds{code}
> On a JVM which has multiple cores, this will become impossible to tell where 
> it's coming from if MDC context is not set



--
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-12344) SolrSlf4jReporter doesn't set MDC context

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-12344:
-
Fix Version/s: 7.5

> SolrSlf4jReporter doesn't set MDC context
> -
>
> Key: SOLR-12344
> URL: https://issues.apache.org/jira/browse/SOLR-12344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Varun Thacker
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.5
>
> Attachments: SOLR-12344.patch
>
>
> I setup a slf4j reporter like this on master
> solr.xml
> {code:java}
> 
>class="org.apache.solr.metrics.reporters.SolrSlf4jReporter">
> 1
> UPDATE./update.requestTimes
> update_logger
>   
> {code}
> log4j2.xml
> {code:java}
> 
> 
> 
>   
> 
>   
> 
>   %-4r [%t] %-5p %c %x [%X{collection} %X{shard} %X{replica} 
> %X{core}] %c; %m%n
> 
>   
> 
>  name="RollingFile"
> fileName="${sys:solr.log.dir}/solr.log"
> filePattern="${sys:solr.log.dir}/solr.log.%i" >
>   
> 
>   %-5p - %d{-MM-dd HH:mm:ss.SSS}; [%X{collection} %X{shard} 
> %X{replica} %X{core}] %c; %m%n
> 
>   
>   
> 
> 
>   
>   
> 
>  name="RollingMetricFile"
> fileName="${sys:solr.log.dir}/solr_metric.log"
> filePattern="${sys:solr.log.dir}/solr_metric.log.%i" >
>   
> 
>   %-5p - %d{-MM-dd HH:mm:ss.SSS}; [%X{collection} %X{shard} 
> %X{replica} %X{core}] %c; %m%n
> 
>   
>   
> 
> 
>   
>   
> 
>   
>   
> 
> 
> 
> 
>   
> 
> 
>   
>   
> 
>   
> 
> {code}
> The output I get from the solr_metric.log file is like this
> {code:java}
> INFO  - 2018-05-11 15:31:16.009; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds
> INFO  - 2018-05-11 15:31:17.010; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds
> INFO  - 2018-05-11 15:31:18.010; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds{code}
> On a JVM which has multiple cores, this will become impossible to tell where 
> it's coming from if MDC context is not set



--
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-12614) Make "Nodes" tab the default in AdminUI Cloud view

[JIRA]

Jan Høydahl created SOLR-12614:
--

 Summary: Make "Nodes" tab the default in AdminUI Cloud view
 Key: SOLR-12614
 URL: https://issues.apache.org/jira/browse/SOLR-12614
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: master (8.0)


The Nodes tab was added in version 7.5, but "Graph" was still the default tab. 
Make the new Nodes tab the default one when opening the "Cloud" view.



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

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

[jira] [Assigned] (SOLR-12541) Metrics handler throws an error if there are transient cores

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  reassigned SOLR-12541:


Assignee: Andrzej Bialecki 

> Metrics handler throws an error if there are transient cores
> 
>
> Key: SOLR-12541
> URL: https://issues.apache.org/jira/browse/SOLR-12541
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2.1
>Reporter: Nandakishore Krishna
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> My environment is as follows
>  * Solr 7.2.1 in standalone mode.
>  * 32GB heap
>  * 150 cores with data getting continuously ingested to ~10 cores and all of 
> the cores queried.
>  * transient cache size is set to 30.
> The solr.xml is as follows
> {code:xml}
> 
> 
>   32
>   true
>   ${configSetBaseDir:configsets}
>   class="HttpShardHandlerFactory">
> ${socketTimeout:60}
> ${connTimeout:6}
>   
> 
> {code}
> I get the following error when I request for "/solr/admin/metrics".
> {code}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 31
> },
> "error": {
> "msg": "Already closed",
> "trace": "org.apache.lucene.store.AlreadyClosedException: Already 
> closed\n\tat 
> org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:337)\n\tat
>  org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:351)\n\tat 
> org.apache.solr.core.SolrCore.getIndexDir(SolrCore.java:330)\n\tat 
> org.apache.solr.handler.ReplicationHandler.lambda$initializeMetrics$5(ReplicationHandler.java:849)\n\tat
>  
> org.apache.solr.util.stats.MetricUtils.convertGauge(MetricUtils.java:488)\n\tat
>  
> org.apache.solr.util.stats.MetricUtils.convertMetric(MetricUtils.java:274)\n\tat
>  
> org.apache.solr.util.stats.MetricUtils.lambda$toMaps$4(MetricUtils.java:213)\n\tat
>  
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)\n\tat 
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)\n\tat
>  
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)\n\tat
>  java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)\n\tat 
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)\n\tat 
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)\n\tat
>  
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)\n\tat
>  
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)\n\tat
>  java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)\n\tat 
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)\n\tat 
> org.apache.solr.util.stats.MetricUtils.toMaps(MetricUtils.java:211)\n\tat 
> org.apache.solr.handler.admin.MetricsHandler.handleRequestBody(MetricsHandler.java:108)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:735)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:716)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:497)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>  
> 

[jira] [Commented] (LUCENE-8442) testPendingDeleteDVGeneration fails with NoSuchFileException

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8442:


| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 18s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m 
33s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 13m 52s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8442 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12933999/LUCENE-8442.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu 
Jun 14 13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 868e970 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/61/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/61/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> testPendingDeleteDVGeneration fails with NoSuchFileException
> 
>
> Key: LUCENE-8442
> URL: https://issues.apache.org/jira/browse/LUCENE-8442
> Project: Lucene - Core
>  Issue Type: Test
>Affects Versions: master (8.0), 7.5
>Reporter: Nhat Nguyen
>Priority: Minor
> Attachments: LUCENE-8442.patch
>
>
> {noformat}
> reproduce with: ant test  -Dtestcase=TestIndexWriter 
> -Dtests.method=testPendingDeleteDVGeneration -Dtests.seed=EAD8920740472544 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=hu-HU 
> -Dtests.timezone=Europe/Nicosia -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.05s J3 | TestIndexWriter.testPendingDeleteDVGeneration 
> <<<
>[junit4]> Throwable #1: java.nio.file.NoSuchFileException: 
> /var/lib/jenkins/workspace/apache+lucene-solr+master/lucene/build/core/test/J3/temp/lucene.index.TestIndexWriter_EAD8920740472544-001/tempDir-001/_2.fdx
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([EAD8920740472544:6D2DCD1227F98DC4]:0)
>[junit4]>  at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>[junit4]>  at 
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>[junit4]>  at 
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>[junit4]>  at 
> sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
>[junit4]>  at 
> org.apache.lucene.mockfile.FilterFileSystemProvider.newByteChannel(FilterFileSystemProvider.java:212)
>[junit4]>  at 
> org.apache.lucene.mockfile.FilterFileSystemProvider.newByteChannel(FilterFileSystemProvider.java:212)
>[junit4]>  at 
> org.apache.lucene.mockfile.FilterFileSystemProvider.newByteChannel(FilterFileSystemProvider.java:212)
>[junit4]>  at 
> org.apache.lucene.mockfile.HandleTrackingFS.newByteChannel(HandleTrackingFS.java:240)
>[junit4]>  at 
> 

[jira] [Commented] (SOLR-12344) SolrSlf4jReporter doesn't set MDC context

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12344:


Commit 5de10c79668bf786d9699db992bf85e2f4beb8b4 in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5de10c7 ]

SOLR-12344: SolrSlf4jReporter doesn't set MDC context.


> SolrSlf4jReporter doesn't set MDC context
> -
>
> Key: SOLR-12344
> URL: https://issues.apache.org/jira/browse/SOLR-12344
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Varun Thacker
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12344.patch
>
>
> I setup a slf4j reporter like this on master
> solr.xml
> {code:java}
> 
>class="org.apache.solr.metrics.reporters.SolrSlf4jReporter">
> 1
> UPDATE./update.requestTimes
> update_logger
>   
> {code}
> log4j2.xml
> {code:java}
> 
> 
> 
>   
> 
>   
> 
>   %-4r [%t] %-5p %c %x [%X{collection} %X{shard} %X{replica} 
> %X{core}] %c; %m%n
> 
>   
> 
>  name="RollingFile"
> fileName="${sys:solr.log.dir}/solr.log"
> filePattern="${sys:solr.log.dir}/solr.log.%i" >
>   
> 
>   %-5p - %d{-MM-dd HH:mm:ss.SSS}; [%X{collection} %X{shard} 
> %X{replica} %X{core}] %c; %m%n
> 
>   
>   
> 
> 
>   
>   
> 
>  name="RollingMetricFile"
> fileName="${sys:solr.log.dir}/solr_metric.log"
> filePattern="${sys:solr.log.dir}/solr_metric.log.%i" >
>   
> 
>   %-5p - %d{-MM-dd HH:mm:ss.SSS}; [%X{collection} %X{shard} 
> %X{replica} %X{core}] %c; %m%n
> 
>   
>   
> 
> 
>   
>   
> 
>   
>   
> 
> 
> 
> 
>   
> 
> 
>   
>   
> 
>   
> 
> {code}
> The output I get from the solr_metric.log file is like this
> {code:java}
> INFO  - 2018-05-11 15:31:16.009; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds
> INFO  - 2018-05-11 15:31:17.010; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds
> INFO  - 2018-05-11 15:31:18.010; [   ] update_logger; type=TIMER, 
> name=UPDATE./update.requestTimes, count=0, min=0.0, max=0.0, mean=0.0, 
> stddev=0.0, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0, 
> mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second, 
> duration_unit=milliseconds{code}
> On a JVM which has multiple cores, this will become impossible to tell where 
> it's coming from if MDC context is not set



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest

Error Message:
Could not load collection from ZK: replicaTypesTestColl

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
replicaTypesTestColl
at 
__randomizedtesting.SeedInfo.seed([6E3C175EE2BC47F7:55D6B4E885258AFB]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1316)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:732)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:154)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest(CloudSolrClientTest.java:867)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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)

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 278 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/278/

2 tests failed.
FAILED:  org.apache.lucene.document.TestLatLonPolygonShapeQueries.testRandomBig

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([4B481C8C763E2E70:CC1F6103E76752F0]:0)
at org.apache.lucene.util.ArrayUtil.growExact(ArrayUtil.java:302)
at org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:311)
at 
org.apache.lucene.index.PointValuesWriter.addPackedValue(PointValuesWriter.java:59)
at 
org.apache.lucene.index.DefaultIndexingChain.indexPoint(DefaultIndexingChain.java:515)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:473)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:394)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:251)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1601)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1220)
at 
org.apache.lucene.document.TestLatLonPolygonShapeQueries.indexRandomPolygons(TestLatLonPolygonShapeQueries.java:193)
at 
org.apache.lucene.document.TestLatLonPolygonShapeQueries.verify(TestLatLonPolygonShapeQueries.java:143)
at 
org.apache.lucene.document.TestLatLonPolygonShapeQueries.doTestRandom(TestLatLonPolygonShapeQueries.java:136)
at 
org.apache.lucene.document.TestLatLonPolygonShapeQueries.testRandomBig(TestLatLonPolygonShapeQueries.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)


FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([A4B55475AC7193AF:932EA06B94BD4E0B]: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.TestSolrCloudWithDelegationTokens.renewDelegationToken(TestSolrCloudWithDelegationTokens.java:132)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.verifyDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:316)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:333)
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 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+24) - Build # 22582 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22582/
Java: 64bit/jdk-11-ea+24 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
9 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest: 1) 
Thread[id=15545, name=zkCallback-3754-thread-2, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)2) 
Thread[id=15607, name=zkCallback-3754-thread-4, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)3) 
Thread[id=15111, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)4) 
Thread[id=15137, name=zkCallback-3754-thread-1, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:834)5) 
Thread[id=15113, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[B97AE36E9D551264]-EventThread,
 state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
 at java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)6) 
Thread[id=15112, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[B97AE36E9D551264]-SendThread(127.0.0.1:39273),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]  
   at java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 

[jira] [Updated] (LUCENE-8424) Payload null value exception handling

[Tapan Vaishnav (JIRA)]

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

Tapan Vaishnav updated LUCENE-8424:
---
Attachment: LUCENE-8424.patch

> Payload null value exception handling
> -
>
> Key: LUCENE-8424
> URL: https://issues.apache.org/jira/browse/LUCENE-8424
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.2, 7.3.1
>Reporter: Tapan Vaishnav
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch
>
>
> If-Condition to check payload null value in _PayloadScoreQuery.java_ was 
> removed in LUCENE-8038. Because of that, regarding of the payload value, 
> _payloadsSeen_ is always getting increment. This has compromised the overall 
> score of the document(for instance, as payloadSeens is always greater than 0, 
> docScore() in _MinPayloadFunction.java_ only returns payloadScore which can 
> be zero depending on the payload value). Ideally, it should've returned 1 in 
> case of _payload==null_.
> I have added a simple patch to get started, Please let me know if it needs 
> any improvements. 
> Thanks in advance.



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

Keeping RefGuide screenshots up to date

[Jan Høydahl]

In SOLR-12613 we'll rename the "Cloud" menu in Admin UI to "Cluster". This 
affects pretty much
all admin UI screenshots in the Reference Guide, so the next question then is 
"How do we
keep all those screenshots up to date?". I counted a total of 42 screen shots 
of the UI, many
which require creating collections, adding data, typing things into the UI etc 
up front.

Due to the work involved, we often tend to update only a few shots and leave 
others as-is even
if they are inaccurate. Example is the new "Suggestions" menu tab - there are 
27 screen
shots in the ref guide which are not updated with that menu option.

For SOLR-12613 I'm tempted to only update the four images in "cloud-screens" 
folder for now.

Perhaps for the future an automated approach can be taken using Selenium, as 
outlined in
this post: https://blog.codeship.com/automating-screenshots-in-documentation/ 
This could
in first phase be a standalone tool to generate screenshots but could also be 
extended with
other tests to get some validation of the UI itself, which is completely 
lacking today. WDYT?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


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

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

[JIRA]

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

Jan Høydahl updated SOLR-8207:
--
Attachment: (was: SOLR-8207-refguide.patch)

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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

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

Jan Høydahl commented on SOLR-8207:
---

Ideally we'd rename the URL part, the refGuide page names (and thus URLs) etc. 
A redirect from ~cloud to ~cluster would help.

The term "Cloud tab" or "Cloud view" is quite familiar to many, and this change 
would surely also affect a bunch of docs, blog posts, books, training courses 
etc out there, begging the question if it is worth it :)

I spin off the menu tab renaming into its own issue in SOLR-12613 and propose 
to commit that only for master branch, not 7.x

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-8207-refguide.patch, node-compact.png, 
> node-details.png, node-hostcolumn.png, node-toggle-row-numdocs.png, 
> nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2468/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestWithCollection.testDeleteWithCollection

Error Message:
Error from server at https://127.0.0.1:40829/solr: Could not find collection : 
testDeleteWithCollection_abc

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:40829/solr: Could not find collection : 
testDeleteWithCollection_abc
at 
__randomizedtesting.SeedInfo.seed([3CDFE90D4734F1BE:47061EE01EAE2300]: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.TestWithCollection.testDeleteWithCollection(TestWithCollection.java:197)
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 

[jira] [Created] (SOLR-12613) Rename "Cloud" tab as "Cluster" in Admin UI

[JIRA]

Jan Høydahl created SOLR-12613:
--

 Summary: Rename "Cloud" tab as "Cluster" in Admin UI
 Key: SOLR-12613
 URL: https://issues.apache.org/jira/browse/SOLR-12613
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Reporter: Jan Høydahl
 Fix For: master (8.0)


Spinoff from SOLR-8207. When adding more cluster-wide functionality to the 
Admin UI, it feels better to name the "Cloud" UI tab as "Cluster".

In addition to renaming the "Cloud" tab, we should also change the URL part 
from {{~cloud}} to {{~cluster}}, update reference guide page names, screenshots 
and references etc.

I propose this change is not introduced in 7.x due to the impact, so tagged it 
as fix-version 8.0.



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

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

[jira] [Commented] (SOLR-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=16566528#comment-16566528
 ] 

Upayavira commented on SOLR-8207:
-

You said above that you would keep the link as ~cloud. I would suggest that 
that is likely to create confusion in the future. How about change the active 
link to ~cluster, but make ~cloud work too, or make ~cloud a redirect to 
~cluster? That way, anyone who expects the old URL to work won't be 
disappointed, yet at the same time the UI is consistent within itself?

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-8207-refguide.patch, node-compact.png, 
> node-details.png, node-hostcolumn.png, node-toggle-row-numdocs.png, 
> nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 64573c142c851741da50f8858c9d630557a151d0

[repro] Repro line:  ant test  -Dtestcase=ShardSplitTest 
-Dtests.method=testSplitWithChaosMonkey -Dtests.seed=F8EA4327309875AB 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=sr-ME -Dtests.timezone=Australia/Perth -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestLargeCluster 
-Dtests.method=testNodeLost -Dtests.seed=F8EA4327309875AB -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=be-BY 
-Dtests.timezone=America/North_Dakota/Center -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: 
868e970816d8bb52f138a1181416438c348c750e
[repro] git fetch
[repro] git checkout 64573c142c851741da50f8858c9d630557a151d0

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

[...truncated 3317 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.ShardSplitTest|*.TestLargeCluster" -Dtests.showOutput=onerror  
-Dtests.seed=F8EA4327309875AB -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=sr-ME -Dtests.timezone=Australia/Perth 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

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

[repro] Failures:
[repro]   5/5 failed: org.apache.solr.cloud.api.collections.ShardSplitTest
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster

[repro] Re-testing 100% failures at the tip of master
[repro] git fetch
[repro] git checkout master

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

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

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

[...truncated 3317 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.ShardSplitTest|*.TestLargeCluster" -Dtests.showOutput=onerror  
-Dtests.seed=F8EA4327309875AB -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=sr-ME -Dtests.timezone=Australia/Perth 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

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

[repro] Failures at the tip of master:
[repro]   0/5 failed: org.apache.solr.cloud.api.collections.ShardSplitTest
[repro]   3/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster
[repro] git checkout 868e970816d8bb52f138a1181416438c348c750e

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

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 276 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/276/

No tests ran.

Build Log:
[...truncated 23042 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: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 258: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 264: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 275: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 281: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: WARNING: 
solrcloud-autoscaling-policy-preferences.adoc: line 286: section title out of 
sequence: expected level 4, got level 5
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2239 links (1792 relative) to 3016 anchors in 230 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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-7.x/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.5.0.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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-7.x/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-7.x/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-7.x/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-7.x/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-7.x/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-7.x/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-7.x/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-7.x/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:

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

Jan Høydahl edited comment on SOLR-8207 at 8/2/18 8:14 AM:
---

Thanks for the feedback. I intend to commit to master asap and then get it into 
7.5.

If anyone have time to look at the code in {{AdminHandlersProxy}}, especially 
security aspects, that would be great. Here's an outline of the logic, is it 
water proof?
 # If the {{'nodes'}} parameter is not present in a call to systemInfo and 
metrics handler, then the logic is exactly as before.
 # If {{'nodes'}} param is there, then {{AdminHandlersProxy}} code is executed, 
parsing nodes string as comma separated list of nodeNames
 # If any nodeName is malformed, we throw an exception. Also if one of the node 
names does not exist in live_nodes from zk, we exit. I.e. there should be no 
way to inject bogus URL or node names not part of cluster
 # Then the request is fanned-out by AdminHandlersProxy to all nodes in the 
list and returned in a combined response for consumption by "nodes" tab in 
Admin UI.
 # There's no upper-bound on the number of nodes that can be requested at a 
time, but for "Nodes tab" use typically it will be 10, only the ones rendered 
per page. If {{nodes=all}} is specified, then all live_nodes are consulted. 
Would it make sense to limit the number of nodes in some way? There is a 10s 
timeout for each request, and the worst ting that could happen in a system with 
huge number of nodes is that thins take too much time or times out.

I also like feedback on the approach for parallell sub-queries to all the nodes 
in a loop using Futures. See method {{AdminHandlersProxy#callRemoteNode}} which 
will construct a new SolrClient per sub request:
{code:java}
HttpSolrClient solr = new HttpSolrClient.Builder(baseUrl.toString()).build();
{code}
There is no way to inject an arbitrary URL in there from the API. I tested with 
basic Auth enabled and it seemed to work, indicating that the sub requests use 
PKI authentication or something? Anything that looks shaky?


was (Author: janhoy):
Thanks for the feedback. I intend to commit to master asap and then get it into 
7.5.

If anyone have time to look at the code in {{AdminHandlersProxy}}, especially 
security aspects, that would be great. Here's an outline of the logic, is it 
water proof?
 # If the {{'nodes'}} parameter is not present in a call to systemInfo and 
metrics handler, then the logic is exactly as before.
 # If {{'nodes'}} param is there, then {{AdminHandlersProxy}} code is executed, 
parsing nodes string as comma separated list of nodeNames
 # If any nodeName is malformed, we throw an exception. Also if one of the node 
names does not exist in live_nodes from zk, we exit
 # Then the request is fanned-out by AdminHandlersProxy to all nodes in the 
list and returned in a combined response by Admin UI.
 # There's no upper-bound on the number of nodes that can be requested at a 
time, but typically it will be 10, only the ones rendered per page. If 
{{nodes=all}} is specified, then all live_nodes are consulted. Would it make 
sense to limit the number of nodes in some way? There is a 10s timeout for each 
request, and the worst ting that could happen in a system with huge number of 
nodes is that thins take too much time or times out.

I also like feedback on the approach for parallell sub-queries to all the nodes 
in a loop using Futures. See method {{AdminHandlersProxy#callRemoteNode}} which 
will construct a new SolrClient per sub request:
{code:java}
HttpSolrClient solr = new HttpSolrClient.Builder(baseUrl.toString()).build();
{code}
There is no way to inject an arbitrary URL in there from the API. I tested with 
basic Auth enabled and it seemed to work, indicating that the sub requests use 
PKI authentication or something? Anything that looks shaky?

> 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
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-8207-refguide.patch, node-compact.png, 
> node-details.png, node-hostcolumn.png, node-toggle-row-numdocs.png, 
> nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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 

[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida edited comment on LUCENE-2562 at 8/2/18 8:09 AM:
---

Well..., I am now working for completing a java desktop Luke, in any case.

If someone is strongly interested in a http server & web app version, feel free 
to fork the github repository ( https://github.com/DmitryKey/luke ) and develop 
it. I am the one long for a web version Luke that can access indexes in remote 
server, and will glad to cooperate.


was (Author: tomoko uchida):
Well..., I am now working for completing a java desktop Luke, in any case.

If someone is strongly interested in a http server & web app version, feel free 
to fork the github repository ([https://github.com/DmitryKey/luke)] and develop 
it. I am the one long for a web version Luke that can access indexes in remote 
server, and will glad to cooperate.

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



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

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

[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on LUCENE-2562:
---

Well..., I am now working for completing a java desktop Luke, in any case.

If someone is strongly interested in a http server & web app version, feel free 
to fork the github repository ([https://github.com/DmitryKey/luke)] and develop 
it. I am the one long for a web version Luke that can access indexes in remote 
server, and will glad to cooperate.

> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
>  Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, 
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, 
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, 
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, 
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer": 
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked 
> with trunk - and it would also be great if it was easier to match Luke jars 
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest 
> starting point is to straight port Luke to another UI toolkit before 
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I 
> haven't/don't have a lot of time for this at the moment, but I've plugged 
> away here and there over the past work or two. There is still a *lot* to do.



--
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-12611) Add version information to thread dump

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-12611:


If it's just going to stay dormant, then I'd say object wait is a fine 
solution. Or a Thread.sleep() with a large constant (why 100 millis if it can 
be 24 hours...). I'd also make this thread a daemon thread so that the JVM can 
terminate without even looking at it (and the test framework doesn't consider 
it a live thread escaping the test?).

Also, I was just pointing out the fact, I'm not saying this is the right 
solution to the problem. I understand your rationale, but if somebody can dump 
a stack trace of all threads they can as well inspect the classpath (even that 
of a running process) and get Solr's version from there? On the other hand, if 
it helps with diagnostics, a dormant thread doesn't seem to hurt anybody much.


> Add version information to thread dump
> --
>
> Key: SOLR-12611
> URL: https://issues.apache.org/jira/browse/SOLR-12611
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.4
>Reporter: Shawn Heisey
>Priority: Trivial
> Attachments: SOLR-12611.patch
>
>
> Thread dumps contain stacktrace info.  Without knowing the Solr version, it 
> can be difficult to compare stacktraces to source code.
> If exact version information is available in the thread dump, it will be 
> possible to look at source code to understand stacktrace information.  If 
> *full* version information is present, then it would even be possible to 
> learn whether the user is running an official binary build or if they have 
> built Solr themselves.



--
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-12610) Inject failures during synchronous update requests during shard splits

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-12610:
--

The new {{SOLR-12610-test-cloudclient-retry.patch}} has a test which tests 
retry behavior of CloudSolrClient. The HTTP 500 error from the server is not a 
communication problem and the cluster state is also unchanged and yet the 
CloudSolrClient attempts retries.

> Inject failures during synchronous update requests during shard splits
> --
>
> Key: SOLR-12610
> URL: https://issues.apache.org/jira/browse/SOLR-12610
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12610-test-cloudclient-retry.patch, SOLR-12610.patch
>
>
> In SOLR-12607, I found a bug where the StdNode's shard was not set correctly 
> causing exceptions during updates forwarded to sub-shard leaders to not be 
> sent back to the clients. This can cause data loss during split. A fix was 
> committed as part of SOLR-12607 but we need to expand coverage to this 
> situation. I'll add failure injection during the synchronous update step to 
> simulate this condition. This will be randomized for each shard split test 
> method.



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

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

[jira] [Updated] (SOLR-12610) Inject failures during synchronous update requests during shard splits

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-12610:
-
Attachment: SOLR-12610-test-cloudclient-retry.patch

> Inject failures during synchronous update requests during shard splits
> --
>
> Key: SOLR-12610
> URL: https://issues.apache.org/jira/browse/SOLR-12610
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12610-test-cloudclient-retry.patch, SOLR-12610.patch
>
>
> In SOLR-12607, I found a bug where the StdNode's shard was not set correctly 
> causing exceptions during updates forwarded to sub-shard leaders to not be 
> sent back to the clients. This can cause data loss during split. A fix was 
> committed as part of SOLR-12607 but we need to expand coverage to this 
> situation. I'll add failure injection during the synchronous update step to 
> simulate this condition. This will be randomized for each shard split test 
> method.



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

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testAddNode

Error Message:
trigger did not fire

Stack Trace:
java.lang.AssertionError: trigger did not fire
at 
__randomizedtesting.SeedInfo.seed([30F931FB1E2840A5:97162C58D165CFBD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testAddNode(TestLargeCluster.java:309)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testNodeLost

Error Message:
did not finish processing all events in time: started=5, finished=4

Stack Trace:
java.lang.AssertionError: did not finish processing all events in time: 
started=5, finished=4
at 

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

[Apache Jenkins Server]

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

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

Error Message:
.facet_counts.facet_fields.str.x:0!=null

Stack Trace:
junit.framework.AssertionFailedError: .facet_counts.facet_fields.str.x:0!=null
at 
__randomizedtesting.SeedInfo.seed([83508E9B6738ED8:80613733188FE320]:0)
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:928)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:955)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:613)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:576)
at 
org.apache.solr.cloud.DistribCursorPagingTest.doSimpleTest(DistribCursorPagingTest.java:257)
at 
org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:89)
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:1008)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
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