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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/105/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Doc with id=1 not found in http://127.0.0.1:52462/f/forceleader_test_collection 
due to: Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:52462/f/forceleader_test_collection due to: Path not found: 
/id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([80D2CDC1EE969EAE:6645F901D71467CF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:556)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+181) - Build # 233 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/233/
Java: 64bit/jdk-9-ea+181 -XX:+UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

2 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
Doc with id=1 not found in http://127.0.0.1:43429/sz_qou/wn/collMinRf_1x3 due 
to: Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:43429/sz_qou/wn/collMinRf_1x3 due to: Path not found: /id; 
rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([D79E9D5634D78518:5FCAA28C9A2BE8E0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:558)
at 
org.apache.solr.cloud.HttpPartitionTest.testMinRf(HttpPartitionTest.java:249)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:127)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Commented] (SOLR-11217) Mathematical notation not supported in Solr Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11217:
--

I haven't committed anything for this, although the HTML support is relatively 
straightforward. It's the PDF support that's going to be a pain.

h3. HTML

We can add a MathJax javascript to our templates that will render stem 
notations properly. It supports using {{latexmath}} and {{asciimath}} as macros 
or blocks, or a generic {{stem}} macro/block that defaults to asciimath if the 
more specific form is not used. There are only a couple minor changes to our 
templates for this - add a new JS-based _include file, make sure that's 
included in the header, and make sure {{_config.yml}} is updated to allow stem 
processing.

h3. PDF

MathJax is browser-based, so won't work for PDFs and another solution is 
required.

The Asciidoctor project includes a 
[asciidoctor-mathematical|https://github.com/asciidoctor/asciidoctor-mathematical]
 project. The PDF tool we use (asciidoctor-pdf) supports this, but there are 
several limitations:
* asciidoctor-mathematical has a long list of dependencies and font 
requirements. It took a couple tries at getting these worked out, and the list 
is different for different OS's. Any one of these could be an issue for 
Jenkins, which is subject to INFRA's policies.
* it's not integrated with asciidoctor-ant, which we use for the build. This 
means Jenkins and anyone who wants to build on their local machine needs all 
the dependencies locally to build the PDF (which is true today for the HTML 
version also, but Jekyll has a many fewer dependencies). However, 
asciidoctor-ant should support using it as an extension, assuming we put it in 
the right place.
* asciidoctor-mathematical makes images for the math and inserts those in the 
PDF. These images are also saved as separate .png files (could also support SVG 
if preferred). If these are not properly compressed, I suspect they could make 
the PDF really large (if there are more than 1 or 2 of these).
* it only supports latexmath, and not asciimath. If you preface any notation 
with anything other than {{latexmath}} it doesn't work.

I don't know the extent you and others want to use stem notations in the Ref 
Guide, so can't guess if we can live with all of this. There doesn't seem to be 
anything in the works for asciimath support, so we will always need to use 
latexmath. And we'll be even farther from the goal of figuring out how to allow 
anyone to build the Ref Guide without all the dependencies.

> Mathematical notation not supported in Solr Ref Guide
> -
>
> Key: SOLR-11217
> URL: https://issues.apache.org/jira/browse/SOLR-11217
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Houston Putman
>Priority: Minor
>
> The template used to build the Solr Ref Guide from the asciidoctor pages 
> removes the needed javascript for mathematical notation. 
> When building the webpage, asciidoctor puts a tag like the one below at the 
> bottom of the html
> {code:html}
>  src="#{cdn_base}/mathjax/2.6.0/MathJax.js?config=TeX-MML-AM_HTMLorMML">
> {code}
> and some other tags as well.
> However these are not included in the sections that are inserted into the 
> template, so they are left out and the mathematical notation is not converted 
> to MathJax that can be viewed in a browser.
> This can be tested by adding any stem notation in an asciidoctor 
> solr-ref-page, such as the following text:
> {code}
> asciimath:[sqrt(4) = 2].
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Windows (32bit/jdk1.8.0_144) - Build # 76 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/76/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts\data

C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts

C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr

C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts

C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005

C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts\data\snapshot_metadata:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts\data\snapshot_metadata

C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts\data
   
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr\techproducts
   
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts\solr
   
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005\techproducts
   
C:\Users\jenkins\workspace\Lucene-Solr-7.0-Windows\solr\build\solr-core\test\J0\temp\solr.util.TestSolrCLIRunExample_DF3FC52E0F1B9AC8-001\tempDir-005:
 java.nio.file.DirectoryNotEmptyException: 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+181) - Build # 20290 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20290/
Java: 32bit/jdk-9-ea+181 -client -XX:+UseG1GC --illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Doc with id=1 not found in 
http://127.0.0.1:45025/s/bs/forceleader_test_collection due to: Path not found: 
/id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:45025/s/bs/forceleader_test_collection due to: Path not found: 
/id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([4748DD742FE6FE0E:A1DFE9B41664076F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:556)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:142)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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)

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Doc with id=1 not found in 
http://127.0.0.1:53162/e/c/forceleader_test_collection due to: Path not found: 
/id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:53162/e/c/forceleader_test_collection due to: Path not found: 
/id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([5DE01802659D4589:BB772CC25C1FBCE8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:556)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-11204) Expose a total size stat for the query result and filter cache

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11204:
--

bq. Should {{ConcurrentLRUCache#ramBytesUsed}} synchronize on the map variable 
like {[LRUCache#ramBytesUsed}} ?

It is not necessary. The {{ramBytes}} in ConcurrentLRUCache is an AtomicLong 
but the one in LRUCache is not.

bq. LRUCache and ConcurrentLRUCache only tracks ramBytesUsed when maxRamMB is 
enabled...

The algorithm used for eviction in ConcurrentLRUCache when maxRamMB is 
specified is more inefficient (always makes 3 passes vs usually just 1 pass) 
then when using sizes. This is also the cause of another way in which 
ConcurrentLRUCache is different from LRUCache i.e. LRUCache uses both maxRamMB 
and size for eviction but ConcurrentLRUCache uses only one of them at a time. 
Therefore there was no need to track ram usage if we weren't going to use them.

That being said, tracking ram bytes is not that expensive that we couldn't do 
it by default. But we still cannot support both maxRamMB and max size together.

> Expose a total size stat for the query result and filter cache
> --
>
> Key: SOLR-11204
> URL: https://issues.apache.org/jira/browse/SOLR-11204
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Minor
>
> It will be useful to display the size of the filter cache and query result 
> cache currently being used . We added support for this to the field cache in 
> SOLR-9844



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6811/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

3 tests failed.
FAILED:  
org.apache.lucene.replicator.IndexReplicationClientTest.testConsistencyOnExceptions

Error Message:
Captured an uncaught exception in thread: Thread[id=21, 
name=ReplicationThread-index, state=RUNNABLE, 
group=TGRP-IndexReplicationClientTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=21, name=ReplicationThread-index, 
state=RUNNABLE, group=TGRP-IndexReplicationClientTest]
at 
__randomizedtesting.SeedInfo.seed([530D53C1422E63C8:DC83B46150429037]:0)
Caused by: java.lang.AssertionError: handler failed too many times: -1
at __randomizedtesting.SeedInfo.seed([530D53C1422E63C8]:0)
at 
org.apache.lucene.replicator.IndexReplicationClientTest$4.handleUpdateException(IndexReplicationClientTest.java:304)
at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)


FAILED:  
org.apache.solr.cloud.CdcrBootstrapTest.testConvertClusterToCdcrAndBootstrap

Error Message:
Captured an uncaught exception in thread: Thread[id=881, name=Thread-116, 
state=RUNNABLE, group=TGRP-CdcrBootstrapTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=881, name=Thread-116, state=RUNNABLE, 
group=TGRP-CdcrBootstrapTest]
at 
__randomizedtesting.SeedInfo.seed([A69F587916928C01:7148770EA2CD1446]:0)
Caused by: java.lang.AssertionError: 1
at __randomizedtesting.SeedInfo.seed([A69F587916928C01]:0)
at 
org.apache.solr.core.CachingDirectoryFactory.close(CachingDirectoryFactory.java:192)
at org.apache.solr.core.SolrCore.close(SolrCore.java:1612)
at 
org.apache.solr.core.CoreContainer.registerCore(CoreContainer.java:863)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1236)
at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:900)
at java.lang.Thread.run(Thread.java:748)


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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:741)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:934)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:843)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1002)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:938)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 

[jira] [Created] (SOLR-11220) Extracting original score (OriginalScoreFeature) will return 0.0 in SolrCloud

[Ryan Yacyshyn (JIRA)]

Ryan Yacyshyn created SOLR-11220:


 Summary: Extracting original score (OriginalScoreFeature) will 
return 0.0 in SolrCloud
 Key: SOLR-11220
 URL: https://issues.apache.org/jira/browse/SOLR-11220
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - LTR
Affects Versions: 6.6
Reporter: Ryan Yacyshyn


Attempting to extract the original score as a feature using 
org.apache.solr.ltr.feature.OriginalScoreFeature returns "originalScore=0.0" in 
SolrCloud. "score" is included in the "fl" params.

While testing on a single core, OriginalScoreFeature works as expected.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7827) disable "textgrams" when minPrefixChars=0 AnalyzingInfixSuggester

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7827:
--

Right. I want to make AIS handy for extension. Isn't it worth to do? Or it 
needs to introduce protected getters?

> disable "textgrams" when minPrefixChars=0 AnalyzingInfixSuggester 
> --
>
> Key: LUCENE-7827
> URL: https://issues.apache.org/jira/browse/LUCENE-7827
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-7827.patch, LUCENE-7827.patch, LUCENE-7827.patch, 
> LUCENE-7827.patch
>
>
> The current code allows to set minPrefixChars=0, but it creates an 
> unnecessary {{textgrams}} field, and might bring significant footprint.  
> Bypassing it keeps existing tests green.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-NightlyTests-7.0 - Build # 25 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.0/25/

3 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest.test

Error Message:
Error from server at http://127.0.0.1:55730/m_/r: ADDREPLICA failed to create 
replica

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:55730/m_/r: ADDREPLICA failed to create replica
at 
__randomizedtesting.SeedInfo.seed([177FA75A9BC052C6:9F2B9880353C3F3E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
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:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.testUnloadShardAndCollection(UnloadDistributedZkTest.java:124)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Resolved] (SOLR-11071) Improve TestIntervalFacets.testRandom

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-11071.
--
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

> Improve TestIntervalFacets.testRandom
> -
>
> Key: SOLR-11071
> URL: https://issues.apache.org/jira/browse/SOLR-11071
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11071.patch
>
>
> Should include negative values and dates



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Doc with id=1 not found in http://127.0.0.1:64481/forceleader_test_collection 
due to: Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:64481/forceleader_test_collection due to: Path not found: /id; 
rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([5F76F686428C3AA1:B9E1C2467B0EC3C0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:556)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[GitHub] lucene-solr pull request #224: Fix typo in javadocs

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-11071) Improve TestIntervalFacets.testRandom

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11071:


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

SOLR-11071: Improve TestIntervalFacets.testRandom


> Improve TestIntervalFacets.testRandom
> -
>
> Key: SOLR-11071
> URL: https://issues.apache.org/jira/browse/SOLR-11071
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-11071.patch
>
>
> Should include negative values and dates



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11071) Improve TestIntervalFacets.testRandom

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11071:


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

SOLR-11071: Improve TestIntervalFacets.testRandom


> Improve TestIntervalFacets.testRandom
> -
>
> Key: SOLR-11071
> URL: https://issues.apache.org/jira/browse/SOLR-11071
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-11071.patch
>
>
> Should include negative values and dates



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11204) Expose a total size stat for the query result and filter cache

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11204:
--

Some observations:

1. Should {[ConcurrentLRUCache#ramBytesUsed}} synchronize on the map variable 
like {[LRUCache#ramBytesUsed}} ?
2. LRUCache  and ConcurrentLRUCache only tracks ramBytesUsed when {{maxRamMB}} 
is enabled. LRUCache exposes ( which document cache / query result cache uses 
by default ) but FastLRUCache doesn't ( which is used by filter cache by 
default )

- How much of an overhead is calculating ramBytesUsed ? If it isn't then we can 
we do it even when {maxRamMB}} is not used? That way a user who specifies max 
entries can atleast see in the UI how much heap space are the caches occupying




> Expose a total size stat for the query result and filter cache
> --
>
> Key: SOLR-11204
> URL: https://issues.apache.org/jira/browse/SOLR-11204
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Minor
>
> It will be useful to display the size of the filter cache and query result 
> cache currently being used . We added support for this to the field cache in 
> SOLR-9844



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+181) - Build # 20289 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20289/
Java: 64bit/jdk-9-ea+181 -XX:-UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

3 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Doc with id=1 not found in http://127.0.0.1:33327/forceleader_test_collection 
due to: Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:33327/forceleader_test_collection due to: Path not found: /id; 
rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([2F88C645175B3E58:C91FF2852ED9C739]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:556)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:142)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Commented] (SOLR-11183) why call the API end point /v2 will there ever be a /v3

[JIRA]

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

Jan Høydahl commented on SOLR-11183:


My concern is that if we advertise /v2 as a major feature and the new "default" 
from 7.0, then it gets harder and harder to change the URL since so many users 
out there will have adopted /v2, the same with all docs, blogs etc.

If it is very hard to change the /v2 end-point name, then the design probably 
has too much redundant hard coding? I find 44 occurrences of {{/v2}} and 20 
occurrences of {{v2}} in the code base, including comments and docs.

> why call the API end point /v2 will there ever be a /v3
> ---
>
> Key: SOLR-11183
> URL: https://issues.apache.org/jira/browse/SOLR-11183
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.1
>
>
> The mail thread
> http://lucene.472066.n3.nabble.com/v2-API-will-there-ever-be-a-v3-td4340901.html
> it makes sense to prefix v2 APIs at {{/api}} intsead of {{/v2}} if we never 
> plan to have a {{/v3}}
> In principle, it makes total sense
> The challenge is that it takes a while to change the code and tests to make 
> to work. Should this be a blocker and should we hold up the release



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10595) Redirect Confluence pages to new HTML Guide

[JIRA]

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

Jan Høydahl commented on SOLR-10595:


bq. This already exists - put in 
https://lucene.apache.org/solr/guide/coreadmin-api.html and it redirects to 
https://lucene.apache.org/solr/guide/6_6/coreadmin-api.html. 

This will not survive renames or restructuring. An elegant approach would be 
that {{/solr/guide/foo}} would return the page from the *latest* version that 
returns a 200 response for that page name. I.e. we could have a CGI that either 
looks up a static list of valid pages per release or attempts a HEAD request 
against newest first and then each older release before returning a 301 
redirect to the correct page.

> Redirect Confluence pages to new HTML Guide
> ---
>
> Key: SOLR-10595
> URL: https://issues.apache.org/jira/browse/SOLR-10595
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Hoss Man
> Attachments: new-page-urls.txt, page-tree.xml
>
>
> Once the new Ref Guide is live, we may want to redirect pages from Confluence 
> to the new HTML version. 
> I'm undecided if this is the best idea, I can see pros and cons to it. On the 
> pro side, I think it helps firmly establish the move away from Confluence and 
> helps users adjust to the new location. But I could see the argument that 
> redirecting is overly invasive or unnecessary and we should just add a big 
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell 
> Confluence to add to the HEAD of each page to auto-redirect. With some 
> probably simple modifications to it, we could get people to the right page in 
> the HTML site: 
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: withShardField
at 
__randomizedtesting.SeedInfo.seed([3FA8AFC2B1AF5B08:6AF847501D5694F8]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1139)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:822)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Commented] (SOLR-11219) Update SolrFieldCacheBean description to indicate the information is for the CoreContainer (all cores) and not each core

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11219:
--

+1 . It's not obvious that it's a static 

> Update SolrFieldCacheBean description to indicate the information is for the 
> CoreContainer (all cores) and not each core
> 
>
> Key: SOLR-11219
> URL: https://issues.apache.org/jira/browse/SOLR-11219
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Tomás Fernández Löbbe
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11219) Update SolrFieldCacheBean description to indicate the information is for the CoreContainer (all cores) and not each core

[JIRA]

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


 Summary: Update SolrFieldCacheBean description to indicate the 
information is for the CoreContainer (all cores) and not each core
 Key: SOLR-11219
 URL: https://issues.apache.org/jira/browse/SOLR-11219
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: metrics
Reporter: Tomás Fernández Löbbe
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Pathological index condition

[Erick Erickson]

Thanks Mike:

bq: Or are you saying that each segments 20% of not-deleted docs is
still greater than 1/2 of the max segment size, and so TMP considers
them ineligible?

Exactly.

Hadn't seen the blog, thanks for that. Added to my list of things to refer to.

The problem we're seeing is that "in the wild" there are cases where
people can now get satisfactory performance from huge numbers of
documents, as in close to 2B (there was a question on the user's list
about that recently). So allowing up to 60% deleted documents is
dangerous in that situation.

And the situation is exacerbated by optimizing (I know, "don't do that").

Ah, well, the joys of people using this open source thing and pushing
its limits.

Thanks again,
Erick

On Tue, Aug 8, 2017 at 3:49 PM, Michael McCandless
 wrote:
> Hi Erick,
>
> Some questions/answers below:
>
> On Sun, Aug 6, 2017 at 8:22 PM, Erick Erickson 
> wrote:
>>
>> Particularly interested if Mr. McCandless has any opinions here.
>>
>> I admit it took some work, but I can create an index that never merges
>> and is 80% deleted documents using TieredMergePolicy.
>>
>> I'm trying to understand how indexes "in the wild" can have > 30%
>> deleted documents. I think the root issue here is that
>> TieredMergePolicy doesn't consider for merging any segments > 50% of
>> maxMergedSegmentMB of non-deleted documents.
>>
>> Let's say I have segments at the default 5G max. For the sake of
>> argument, it takes exactly 5,000,000 identically-sized documents to
>> fill the segment to exactly 5G.
>>
>> IIUC, as long as the segment has more than 2,500,000 documents in it
>> it'll never be eligible for merging.
>
>
> That's right.
>
>>
>> The only way to force deleted
>> docs to be purged is to expungeDeletes or optimize, neither of which
>> is recommended.
>
>
> +1
>
>> The condition I created was highly artificial but illustrative:
>> - I set my max segment size to 20M
>> - Through experimentation I found that each segment would hold roughly
>> 160K synthetic docs.
>> - I set my ramBuffer to 1G.
>> - Then I'd index 500K docs, then delete 400K of them, and commit. This
>> produces a single segment occupying (roughly) 80M of disk space, 15M
>> or so of it "live" documents the rest deleted.
>> - rinse, repeat with a disjoint set of doc IDs.
>>
>> The number of segments continues to grow forever, each one consisting
>> of 80% deleted documents.
>
>
> But wouldn't TMP at some point merge these segments?  Or are you saying that
> each segments 20% of not-deleted docs is still greater than 1/2 of the max
> segment size, and so TMP considers them ineligible?
>
> This is indeed a rather pathological case, and you're right TMP would never
> merge them (if my logic above is right).  Maybe we could tweak TMP for
> situations like this, though I'm not sure they happen in practice.  Normally
> the max segment size is quite a bit larger than the initially flushed
> segment sizes.
>
>>
>> This artificial situation just allowed me to see how the segments
>> merged. Without such artificial constraints I suspect the limit for
>> deleted documents would be capped at 50% theoretically and in practice
>> less than that although I have seen 35% or so deleted documents in the
>> wild.
>
>
> Yeah I think so too.  I wrote this blog post about deletions:
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents
>
> It has a fun chart showing how the %tg deleted docs bounces around.
>
>>
>> So at the end of the day I have a couple of questions:
>>
>> 1> Is my understanding close to correct? This is really the first time
>> I've had to dive into the guts of merging.
>
>
> Yes!
>
>>
>> 2> Is there a way I've missed to slim down an index other than
>> expungedeletes of optimize/forcemerge?
>
>
> No.
>
>> It seems to me like eventually, with large indexes, every segment that
>> is the max size allowed is going to have to go over 50% deletes before
>> being merged and there will have to be at least two of them. I don't
>> see a clean way to fix this, any algorithm would likely be far too
>> expensive to be part of regular merging. I suppose we could merge
>> segments of different sizes if the combined size was < max segment
>> size. On a quick glance it doesn't seem like the log merge policies
>> address this kind of case either, but haven't dug into them much.
>
>
> TMP should be able to merge one max sized segment (that has eek'd just over
> 50% deleted docs) with smaller sized segments.  It would not prefer this
> merge, since merging substantially different segment sizes is poor
> performance vs. merging equally sized segments, but it does have a bias for
> removing deleted docs that would offset that.
>
>>
>> Thanks!
>
>
> You're welcome!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>

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

[JENKINS] Lucene-Solr-7.0-Linux (32bit/jdk1.8.0_144) - Build # 174 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/174/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: 
http://127.0.0.1:43903/oc/ye/collMinRf_1x3_shard1_replica_t2

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: 
http://127.0.0.1:43903/oc/ye/collMinRf_1x3_shard1_replica_t2
at 
__randomizedtesting.SeedInfo.seed([C3CFF1AAF9EED2D0:4B9BCE705712BF28]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:555)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.testMinRf(HttpPartitionTest.java:284)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

What is the expected behavior when you delete one of multiple collections pointed to by an alias?

[Erick Erickson]

I was working on SOLR-11218 as I wanted a test for a particular
behavior. While I was working on it I wondered what would happen if
you
> created two collections
> created an alias pointing to them both
> deleted one of the collections.
> tried to use the alias

What happens is the delete succeeds, the alias remains there but when
you try to use it you get a "No live servers" error.

Is this expected? If not I'll raise a JIRA and check in this test with
an @Ignore as part of 11218

Erick

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

Re: What should we do with the 6x code line?

[Jan Høydahl]

+1


> Den 9. aug. 2017 kl. 20.18 skrev David Smiley :
> 
> +1 
> I think a 6.7 release would be very good.
> 
>> On Tue, Aug 8, 2017 at 5:46 PM Mike Drob  wrote:
>> +1
>> 
>> Release early, release often!
>> 
>>> On Tue, Aug 8, 2017 at 4:27 PM, Erick Erickson  
>>> wrote:
>>> Solr and Lucene have had fixes backported to 6x (not 6.6) since the
>>> 7.0 label was set, most in Solr. Some of the fixes are useful "in the
>>> field", I've back-ported some of them myself.
>>> 
>>> What objections are there to a 6.7 release? We'd always prefer to
>>> release nothing except important bug fixes on a prior branch, but the
>>> release process for 7.0 has taken some time and changes have
>>> accumulated.
>>> 
>>> This might be the last, best time to wrap up 6x with a 6.7 as much as
>>> we can before officially releasing 7.0.
>>> 
>>> What do people think?
>>> 
>>> Erick
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
> http://www.solrenterprisesearchserver.com

[jira] [Updated] (SOLR-11218) Add a test that insures that you can delete the underlying collection if you have an alias of the same name pointing to a different collection

[Erick Erickson (JIRA)]

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

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

Patch, test only. WIP

There's one nocommit. I included a second test that creates an alias pointing 
to two collections, then deleting one of the underlying collections. Deleting 
the underlying collection succeeds, but subsequent queries against the alias 
fail with "No live servers". The alias exists is not deleted though.

Is this expected?

> Add a test that insures that you can delete the underlying collection if you 
> have an alias of the same name pointing to a different collection
> --
>
> Key: SOLR-11218
> URL: https://issues.apache.org/jira/browse/SOLR-11218
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-11218.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11217) Mathematical notation not supported in Solr Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11217:
--

I figured out how to make it work. Not what I was supposed to do today ;) but 
it was a compelling question. I'll add more info on the changes in a bit, just 
didn't want anyone else to work on it as an open question.

> Mathematical notation not supported in Solr Ref Guide
> -
>
> Key: SOLR-11217
> URL: https://issues.apache.org/jira/browse/SOLR-11217
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Houston Putman
>Priority: Minor
>
> The template used to build the Solr Ref Guide from the asciidoctor pages 
> removes the needed javascript for mathematical notation. 
> When building the webpage, asciidoctor puts a tag like the one below at the 
> bottom of the html
> {code:html}
>  src="#{cdn_base}/mathjax/2.6.0/MathJax.js?config=TeX-MML-AM_HTMLorMML">
> {code}
> and some other tags as well.
> However these are not included in the sections that are inserted into the 
> template, so they are left out and the mathematical notation is not converted 
> to MathJax that can be viewed in a browser.
> This can be tested by adding any stem notation in an asciidoctor 
> solr-ref-page, such as the following text:
> {code}
> asciimath:[sqrt(4) = 2].
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11190) GraphQuery not working for string fields that has only docValues

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11190:
--

Forgot to message the PR in the commit message so it won't auto close. Karthik 
can you please close out the PR 

> GraphQuery not working for string fields that has only docValues
> 
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch, 
> SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch
>
>
> Graph traversal is not working if string field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11190) GraphQuery not working for string fields that has only docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11190:


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

SOLR-11190: GraphQuery also supports string fields which are indexed=false and 
docValues=true


> GraphQuery not working for string fields that has only docValues
> 
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch, 
> SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch
>
>
> Graph traversal is not working if string field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11190) GraphQuery not working for string fields that has only docValues

[Varun Thacker (JIRA)]

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

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

Thanks Karthik for the patches and Yonik for the review! 

> GraphQuery not working for string fields that has only docValues
> 
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch, 
> SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch
>
>
> Graph traversal is not working if string field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11190) GraphQuery not working for string fields that has only docValues

[Varun Thacker (JIRA)]

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

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

> GraphQuery not working for string fields that has only docValues
> 
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Attachments: SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch, 
> SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch
>
>
> Graph traversal is not working if string field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11190) GraphQuery not working for string fields that has only docValues

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11190:


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

SOLR-11190: GraphQuery also supports string fields which are indexed=false and 
docValues=true


> GraphQuery not working for string fields that has only docValues
> 
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Attachments: SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch, 
> SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch
>
>
> Graph traversal is not working if string field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11190) GraphQuery not working for string fields that has only docValues

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11190:
--

Previous patch seemed to remove a test 

{code}
-doGraph( params("node_id","node_dps", "edge_id","edge_dps") );
{code}

Adding it back and uploading the patch which I will commit

> GraphQuery not working for string fields that has only docValues
> 
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Attachments: SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch, 
> SOLR-11190.patch, SOLR-11190.patch
>
>
> Graph traversal is not working if string field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 833 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25698 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (13.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 29.0 MB in 0.06 sec (509.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 68.9 MB in 0.13 sec (548.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 79.2 MB in 0.14 sec (557.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6136 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6136 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (276.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 49.8 MB in 0.09 sec (549.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 142.4 MB in 0.28 sec (507.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 143.4 MB in 0.26 sec (559.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   

[jira] [Commented] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11181:
---

[~lmonson], I ran the following with your patch applied to upload 8.0-SNAPSHOT 
artifacts to the Apache Snapshot Repository.

{noformat}
ant -Dm2.repository.id=apache.snapshots.https 
-Dm2.repository.url=https://repository.apache.org/content/repositories/snapshots
 generate-maven-artifacts
{noformat}

You can see the result for {{lucene-core}} here (artifacts share the infix 
{{-8.0.0-20170809.185958-28.}}): 
https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-core/8.0.0-SNAPSHOT/

Unlike all previous runs, neither {{-sources}} nor {{-javadoc}} artifacts were 
uploaded when I used your patch.  This is not acceptable.  When you run with 
your patch, do these artifacts get uploaded?

Next I'll try to reproduce the problem you're trying to solve with the 
unpatched build.


> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11190) GraphQuery not working for string fields that has only docValues

[Varun Thacker (JIRA)]

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

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

Updated Karthik's patch with some more validation. All tests pass. I'll give it 
another review and commit it 

> GraphQuery not working for string fields that has only docValues
> 
>
> Key: SOLR-11190
> URL: https://issues.apache.org/jira/browse/SOLR-11190
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.6
>Reporter: Karthik Ramachandran
>Assignee: Karthik Ramachandran
> Attachments: SOLR-11190.patch, SOLR-11190.patch, SOLR-11190.patch, 
> SOLR-11190.patch, SOLR-11190.patch
>
>
> Graph traversal is not working if string field has only docValues since the 
> construction of leaf or parent node queries uses only TermQuery.
> \\ \\
> {code:xml|title=managed-schema|borderStyle=solid}
> 
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
>  docValues="true" />
> id
> 
>  precisionStep="0" positionIncrementGap="0"/>
> 
> {code}
> {code}
> curl -XPOST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/graph/update' --data-binary ' {
>  "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
>  "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
>  "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
>  "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } 
> },
>  "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } 
> },
>  "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } 
> },
>  "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } 
> },
>  "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } 
> },
>  "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 
> Child1" } },
>  "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 
> Child2" } },
>  "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 
> Child1" } },
>  "commit" : {}
> }'
> {code}
> {code}
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
> to=id}id:1
> or
> http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
> to=parentid}id:122
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11217) Mathematical notation not supported in Solr Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11217:
--

OK, got a quick reply. The Asciidoctor part is working properly if {{:stem:}} 
is added to the page front-matter in the sense that it wraps the notation in 
markup for MathJax to do its part rendering it. So, we need to add MathJax to 
our templates as you thought.

The question now is how to add it - I tried a couple of variations of simply 
adding it as a script in the header or page template, but it's going to be a 
little bit more complex than that. I'll see if I can find time in the coming 
days to work some more on getting this to work.

> Mathematical notation not supported in Solr Ref Guide
> -
>
> Key: SOLR-11217
> URL: https://issues.apache.org/jira/browse/SOLR-11217
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Houston Putman
>Priority: Minor
>
> The template used to build the Solr Ref Guide from the asciidoctor pages 
> removes the needed javascript for mathematical notation. 
> When building the webpage, asciidoctor puts a tag like the one below at the 
> bottom of the html
> {code:html}
>  src="#{cdn_base}/mathjax/2.6.0/MathJax.js?config=TeX-MML-AM_HTMLorMML">
> {code}
> and some other tags as well.
> However these are not included in the sections that are inserted into the 
> template, so they are left out and the mathematical notation is not converted 
> to MathJax that can be viewed in a browser.
> This can be tested by adding any stem notation in an asciidoctor 
> solr-ref-page, such as the following text:
> {code}
> asciimath:[sqrt(4) = 2].
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/231/
Java: 64bit/jdk-9-ea+181 -XX:+UseCompressedOops -XX:+UseParallelGC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Doc with id=1 not found in http://127.0.0.1:42565/forceleader_test_collection 
due to: Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:42565/forceleader_test_collection due to: Path not found: /id; 
rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([52C5C44F60220C91:B452F08F59A0F5F0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:556)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:142)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Commented] (SOLR-11218) Add a test that insures that you can delete the underlying collection if you have an alias of the same name pointing to a different collection

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11218:
---

It's common to recommend when people need to re-index for any reason that they:
1> create a new collection
2> index the corpus to the new collection and verify it
3> create an alias pointing to the new collection as their original collection
4> delete the old collection.
  
They may or may not have an alias already pointing to the old collection that's 
being replaced.
If they don't already have an alias, this leaves them with:
  
> a collection named old_collection
> a collection named new_collection
> an alias old_collection->new_collection
  
What happens when the delete old_collection now?
  
Current behavior is that delete "does the right thing" and deletes 
old_collection rather than new_collection,
but if this behavior changes it could be disastrous for users so this test 
insures that this behavior.

I have a test patch in progress I'll commit today if it works.
 

> Add a test that insures that you can delete the underlying collection if you 
> have an alias of the same name pointing to a different collection
> --
>
> Key: SOLR-11218
> URL: https://issues.apache.org/jira/browse/SOLR-11218
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11218) Add a test that insures that you can delete the underlying collection if you have an alias of the same name pointing to a different collection

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-11218:
-

 Summary: Add a test that insures that you can delete the 
underlying collection if you have an alias of the same name pointing to a 
different collection
 Key: SOLR-11218
 URL: https://issues.apache.org/jira/browse/SOLR-11218
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11218) Add a test that insures that you can delete the underlying collection if you have an alias of the same name pointing to a different collection

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-11218:
-

Assignee: Erick Erickson

> Add a test that insures that you can delete the underlying collection if you 
> have an alias of the same name pointing to a different collection
> --
>
> Key: SOLR-11218
> URL: https://issues.apache.org/jira/browse/SOLR-11218
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11217) Mathematical notation not supported in Solr Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11217:
--

I hadn't realized until now that Asciidoctor had stem notation support built 
into it. According to Asciidoctor docs 
(http://asciidoctor.org/docs/user-manual/#activating-stem-support), it's as 
simple as adding a {{:stem:}} attribute to a page (or globally, which we would 
prefer). If I add that to a page and use Asciidoctor itself to convert the page 
to HTML it works well.

In order to support it for Jekyll, we'd change the attribute slightly to 
{{:page-stem:}}. Note we're not using Asciidoctor's converters to build our 
HTML, we're using Jekyll's with a plugin from the Asciidoctor project to allow 
Jekyll to support AsciiDoc formatted files. Adding the attribute to the page 
front-matter (the stuff at the top of each file), however, has no impact 
whatsoever.

It may be that this is not yet supported, or we need to add something as an 
extension or plugin to Jekyll, or we may need to modify the templates as in 
your suggestion. I've asked the jekyll-asciidoc project what their 
recommendation is: https://github.com/asciidoctor/jekyll-asciidoc/issues/163



> Mathematical notation not supported in Solr Ref Guide
> -
>
> Key: SOLR-11217
> URL: https://issues.apache.org/jira/browse/SOLR-11217
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Houston Putman
>Priority: Minor
>
> The template used to build the Solr Ref Guide from the asciidoctor pages 
> removes the needed javascript for mathematical notation. 
> When building the webpage, asciidoctor puts a tag like the one below at the 
> bottom of the html
> {code:html}
>  src="#{cdn_base}/mathjax/2.6.0/MathJax.js?config=TeX-MML-AM_HTMLorMML">
> {code}
> and some other tags as well.
> However these are not included in the sections that are inserted into the 
> template, so they are left out and the mathematical notation is not converted 
> to MathJax that can be viewed in a browser.
> This can be tested by adding any stem notation in an asciidoctor 
> solr-ref-page, such as the following text:
> {code}
> asciimath:[sqrt(4) = 2].
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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 # 130 - Still Unstable

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

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

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


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([9EA2F281189DD6EA:A37A5CAD2073889A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6810/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Live Nodes: 
[127.0.0.1:55396_solr, 127.0.0.1:55397_solr] Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"MissingSegmentRecoveryTest_shard1_replica_n1", 
  "base_url":"https://127.0.0.1:55396/solr;,   
"node_name":"127.0.0.1:55396_solr",   "state":"down",   
"type":"NRT"}, "core_node4":{   
"core":"MissingSegmentRecoveryTest_shard1_replica_n2",   
"base_url":"https://127.0.0.1:55397/solr;,   
"node_name":"127.0.0.1:55397_solr",   "state":"active",   
"type":"NRT",   "leader":"true",   "router":{"name":"compositeId"}, 
  "maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"2",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Live Nodes: [127.0.0.1:55396_solr, 127.0.0.1:55397_solr]
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n1",
  "base_url":"https://127.0.0.1:55396/solr;,
  "node_name":"127.0.0.1:55396_solr",
  "state":"down",
  "type":"NRT"},
"core_node4":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n2",
  "base_url":"https://127.0.0.1:55397/solr;,
  "node_name":"127.0.0.1:55397_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([891B1F51BD4EB834:D94E8752E46F0E29]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 

Re: What should we do with the 6x code line?

[David Smiley]

+1
I think a 6.7 release would be very good.

On Tue, Aug 8, 2017 at 5:46 PM Mike Drob  wrote:

> +1
>
> Release early, release often!
>
> On Tue, Aug 8, 2017 at 4:27 PM, Erick Erickson 
> wrote:
>
>> Solr and Lucene have had fixes backported to 6x (not 6.6) since the
>> 7.0 label was set, most in Solr. Some of the fixes are useful "in the
>> field", I've back-ported some of them myself.
>>
>> What objections are there to a 6.7 release? We'd always prefer to
>> release nothing except important bug fixes on a prior branch, but the
>> release process for 7.0 has taken some time and changes have
>> accumulated.
>>
>> This might be the last, best time to wrap up 6x with a 6.7 as much as
>> we can before officially releasing 7.0.
>>
>> What do people think?
>>
>> Erick
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Updated] (SOLR-11146) Analytics Component 2.0 Bug Fixes

[Houston Putman (JIRA)]

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

Houston Putman updated SOLR-11146:
--
Issue Type: Bug  (was: Improvement)

> Analytics Component 2.0 Bug Fixes
> -
>
> Key: SOLR-11146
> URL: https://issues.apache.org/jira/browse/SOLR-11146
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1
>Reporter: Houston Putman
>Priority: Critical
> Fix For: 7.0
>
>
> The new Analytics Component has several small bugs in mapping functions and 
> other places. This ticket is a fix for a large number of them. This patch 
> should allow all unit tests created in SOLR-11145 to pass.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10595) Redirect Confluence pages to new HTML Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10595:
--

bq. I'll prep some mapping files and file an INFRA link soon.

+1, I'm on board with what you've outlined so far.

> Redirect Confluence pages to new HTML Guide
> ---
>
> Key: SOLR-10595
> URL: https://issues.apache.org/jira/browse/SOLR-10595
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Hoss Man
> Attachments: new-page-urls.txt, page-tree.xml
>
>
> Once the new Ref Guide is live, we may want to redirect pages from Confluence 
> to the new HTML version. 
> I'm undecided if this is the best idea, I can see pros and cons to it. On the 
> pro side, I think it helps firmly establish the move away from Confluence and 
> helps users adjust to the new location. But I could see the argument that 
> redirecting is overly invasive or unnecessary and we should just add a big 
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell 
> Confluence to add to the HEAD of each page to auto-redirect. With some 
> probably simple modifications to it, we could get people to the right page in 
> the HTML site: 
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-9177) Support oom hook when running Solr in foreground mode

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-9177:
---
Attachment: SOLR-9177.patch

Patch with fix, CHANGES.txt entry in 7.0.0.


> Support oom hook when running Solr in foreground mode
> -
>
> Key: SOLR-9177
> URL: https://issues.apache.org/jira/browse/SOLR-9177
> Project: Solr
>  Issue Type: New Feature
>Reporter: Anshum Gupta
>Assignee: Shawn Heisey
> Attachments: SOLR-9177.patch
>
>
> After reading through the comments on SOLR-8145 and from my own experience, 
> seems like a reasonable number of people run Solr in foreground mode in 
> production.
> To give some more context, I've seen Solr hit OOM, which leads to IW being 
> closed by Lucene. The Solr process hangs in there and without the oom killer, 
> while all queries continue to work, all update requests start failing.
> I think it makes sense to add support to the bin/solr script to add the oom 
> hook when running in fg mode.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-9177) Support oom hook when running Solr in foreground mode

[Shawn Heisey (JIRA)]

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

Shawn Heisey reassigned SOLR-9177:
--

Assignee: Shawn Heisey

> Support oom hook when running Solr in foreground mode
> -
>
> Key: SOLR-9177
> URL: https://issues.apache.org/jira/browse/SOLR-9177
> Project: Solr
>  Issue Type: New Feature
>Reporter: Anshum Gupta
>Assignee: Shawn Heisey
>
> After reading through the comments on SOLR-8145 and from my own experience, 
> seems like a reasonable number of people run Solr in foreground mode in 
> production.
> To give some more context, I've seen Solr hit OOM, which leads to IW being 
> closed by Lucene. The Solr process hangs in there and without the oom killer, 
> while all queries continue to work, all update requests start failing.
> I think it makes sense to add support to the bin/solr script to add the oom 
> hook when running in fg mode.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7924) dynamic infobox on javadocs/tutorials/ref-guide html pages when URL doesn't match "latest" version

[Hoss Man (JIRA)]

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

Hoss Man updated LUCENE-7924:
-
Component/s: general/website

> dynamic infobox on javadocs/tutorials/ref-guide html pages when URL doesn't 
> match "latest" version
> --
>
> Key: LUCENE-7924
> URL: https://issues.apache.org/jira/browse/LUCENE-7924
> Project: Lucene - Core
>  Issue Type: Wish
>  Components: general/website
>Reporter: Hoss Man
>
> Spinning this idea out of some comments/concerns in SOLR-10595...
> It would be nice if all the various "version specific" pages we have (ie: 
> javadocs, tutorials, solr ref-guide) could include some standard snippet of 
> text drawing users attention to the fact that they are looking at docs for an 
> "older" version of lucene/solr -- ideally with a link to the current version. 
> ala...
> {panel}
> This page is part of the documentation refers to Lucene 5.4.0. The current 
> version of [Lucene is 6.6.0|http://lucene.apache.org/core/6_6_0/core/].
> {panel}
> The details of how this could work aren't clear cut -- particularly since for 
> any arbitrary URL the "latest" version of those docs may not contain the 
> exact same path/file (ie: deprecated/moved classes in future releases, 
> etc...) but ideally it would be some very generic mod_include / javascript 
> directive that could be included in all generated HTML, that would only 
> "activate" when the page was loaded from lucene.apache.org and would only 
> inject the "warning" into the page based on the version number in the URL 
> compared to some server side configured version number (ex: the way we 
> already have the "latest" version# hardcoded in our .htaccess file for 
> redirects)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10595) Redirect Confluence pages to new HTML Guide

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10595:
-

bq. But that can be mitigated by flashing a warning that a newer version 
exists, and preferably offer a link to corresponding page for that version.

Spun off into LUCENE-7924

bq. Doing a redirect makes it harder to find, say ADDREPLICA for instance. Does 
it make sense to sequence redirects after search works on the new site?

Adding search to the new ref-guide seems like an orthoginal issue to adding 
redirects.  But for the sake of argument, let's assume for now they should be 
considered part and parcel...

To you, today, as an experienced user of cwiki: adding redirects may make it 
harder to find the docs on ADDREPLICA because you have preconcieved impressions 
that going to an existing page on cwiki.apache.org and doing a search in that 
search box will help you find it -- but the docs you find that way are stale 
and out of date.  A new user -- even if you deliberately instilled in them the 
preconcieved knowledge that going to cwiki is the best way to find docs -- may 
get frustrated when they can't find docs on commands/features added *after* the 
ref-guide migration using that same approach (and the likehook of that 
happening will only increase -- never decrease -- as time goes on and more docs 
are added/changed).  In the more general case that a new user does *NOT* 
already have preconcieved knowledge that going to cwiki is the best way to find 
docs, they are most likely to try and find dogs using google/web-search -- in 
which case the (current) lack of redirects means they are in roughly the same 
boat: they are very likely to first find stale / out of date (and growing more 
out of date daily) documentation.

adding cwiki->lucene.apache.org redirects seems like it can only improve the 
situation for most users -- independent of the question of when/how we add new 
(explicit) search functionality for the current hosted ref-guide.



I'll prep some mapping files and file an INFRA link soon.

> Redirect Confluence pages to new HTML Guide
> ---
>
> Key: SOLR-10595
> URL: https://issues.apache.org/jira/browse/SOLR-10595
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Hoss Man
> Attachments: new-page-urls.txt, page-tree.xml
>
>
> Once the new Ref Guide is live, we may want to redirect pages from Confluence 
> to the new HTML version. 
> I'm undecided if this is the best idea, I can see pros and cons to it. On the 
> pro side, I think it helps firmly establish the move away from Confluence and 
> helps users adjust to the new location. But I could see the argument that 
> redirecting is overly invasive or unnecessary and we should just add a big 
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell 
> Confluence to add to the HEAD of each page to auto-redirect. With some 
> probably simple modifications to it, we could get people to the right page in 
> the HTML site: 
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11144) Analytics Component Documentation

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11144:
--

Thanks for the pull request! I'll assign this to myself and will try to get you 
feedback in the next couple of days.

> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Assignee: Cassandra Targett
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7924) dynamic infobox on javadocs/tutorials/ref-guide html pages when URL doesn't match "latest" version

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-7924:
--

Rough (untested) sketch of how this might work...

* Generated HTML documents can be tweaked to start including something like 
{{}} in all pages -- 
where the relative path {{../../../}} is based on how deep the generated HTML 
doc is in it's "set" of docs (ie: relative to the 'root' of the javadocs for 
this version, or the 'root' of this version of the ref-guide)
** the generated docs can/should include an empty {{latest-warning.html}} file 
at that path, so external users who host their own copy don't get mod_include 
errors for a missing file
* the .htaccess file(s) used on lucene.apache.org can use mod_rewrite rules to 
route any request for {{latest-warning.html}} to a new CGI, preserving the 
(resolved) path from the mod_include request as a "request param" for the CGI 
to use
* the CGI can look at the version# in the path and compare it to the "latest" 
version (which we can start setting in an .htaccess SetEnv variable), outputing 
HTML as needed if they don't match
** the generate HTML can use the original (resolved) path from the request for 
{{latest-warning.html}} to know where to link people to.
* once this is setup and working, it could be backported as far back as we want 
to go, and the hosted javadocs/ref-guides could be regenerated & re-published.



So for example: 

* 
https://lucene.apache.org/core/5_2_0/queries/org/apache/lucene/queries/TermsQuery.html
** {{}}
* .htaccess rewrites https://lucene.apache.org/core/5_2_0/latest-warning.html 
to something like https://lucene.apache.org/latest-warning.cgi?path=core/5_2_0/
* latest-warning.cgi extracts "5_2_0" from {{$path}} and compares it to some 
env variable (currently) set to "6_6_0" and decides to output a warning
** in that generated warning HTML, the URL to link to is built by replacing 
"5_2_0" with "6_6_0" -- ie: https://lucene.apache.org/core/6_6_0/
* if the {{$path}} already matches the latest version, then the CGI generates 
blank output



> dynamic infobox on javadocs/tutorials/ref-guide html pages when URL doesn't 
> match "latest" version
> --
>
> Key: LUCENE-7924
> URL: https://issues.apache.org/jira/browse/LUCENE-7924
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Hoss Man
>
> Spinning this idea out of some comments/concerns in SOLR-10595...
> It would be nice if all the various "version specific" pages we have (ie: 
> javadocs, tutorials, solr ref-guide) could include some standard snippet of 
> text drawing users attention to the fact that they are looking at docs for an 
> "older" version of lucene/solr -- ideally with a link to the current version. 
> ala...
> {panel}
> This page is part of the documentation refers to Lucene 5.4.0. The current 
> version of [Lucene is 6.6.0|http://lucene.apache.org/core/6_6_0/core/].
> {panel}
> The details of how this could work aren't clear cut -- particularly since for 
> any arbitrary URL the "latest" version of those docs may not contain the 
> exact same path/file (ie: deprecated/moved classes in future releases, 
> etc...) but ideally it would be some very generic mod_include / javascript 
> directive that could be included in all generated HTML, that would only 
> "activate" when the page was loaded from lucene.apache.org and would only 
> inject the "warning" into the page based on the version number in the URL 
> compared to some server side configured version number (ex: the way we 
> already have the "latest" version# hardcoded in our .htaccess file for 
> redirects)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11144) Analytics Component Documentation

[Cassandra Targett (JIRA)]

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

Cassandra Targett reassigned SOLR-11144:


Assignee: Cassandra Targett

> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Assignee: Cassandra Targett
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11144) Analytics Component Documentation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-11144:
---

GitHub user HoustonPutman opened a pull request:

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

SOLR-11144: Initial version of the analytics component reference.



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

$ git pull https://github.com/HoustonPutman/lucene-solr 
analytics-solr_ref_guide

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

https://github.com/apache/lucene-solr/pull/229.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 #229


commit 54410ff9d13efcf174cff3ad0d8667cbe84e75a1
Author: Houston Putman 
Date:   2017-08-03T16:33:00Z

SOLR-11144: Initial version of the analytics component reference.




> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #229: SOLR-11144: Initial version of the analytics ...

[HoustonPutman]

GitHub user HoustonPutman opened a pull request:

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

SOLR-11144: Initial version of the analytics component reference.



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

$ git pull https://github.com/HoustonPutman/lucene-solr 
analytics-solr_ref_guide

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

https://github.com/apache/lucene-solr/pull/229.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 #229


commit 54410ff9d13efcf174cff3ad0d8667cbe84e75a1
Author: Houston Putman 
Date:   2017-08-03T16:33:00Z

SOLR-11144: Initial version of the analytics component reference.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Created] (LUCENE-7924) dynamic infobox on javadocs/tutorials/ref-guide html pages when URL doesn't match "latest" version

[Hoss Man (JIRA)]

Hoss Man created LUCENE-7924:


 Summary: dynamic infobox on javadocs/tutorials/ref-guide html 
pages when URL doesn't match "latest" version
 Key: LUCENE-7924
 URL: https://issues.apache.org/jira/browse/LUCENE-7924
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Hoss Man


Spinning this idea out of some comments/concerns in SOLR-10595...

It would be nice if all the various "version specific" pages we have (ie: 
javadocs, tutorials, solr ref-guide) could include some standard snippet of 
text drawing users attention to the fact that they are looking at docs for an 
"older" version of lucene/solr -- ideally with a link to the current version. 
ala...

{panel}
This page is part of the documentation refers to Lucene 5.4.0. The current 
version of [Lucene is 6.6.0|http://lucene.apache.org/core/6_6_0/core/].
{panel}

The details of how this could work aren't clear cut -- particularly since for 
any arbitrary URL the "latest" version of those docs may not contain the exact 
same path/file (ie: deprecated/moved classes in future releases, etc...) but 
ideally it would be some very generic mod_include / javascript directive that 
could be included in all generated HTML, that would only "activate" when the 
page was loaded from lucene.apache.org and would only inject the "warning" into 
the page based on the version number in the URL compared to some server side 
configured version number (ex: the way we already have the "latest" version# 
hardcoded in our .htaccess file for redirects)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle

[Nawab Zada Asad iqbal (JIRA)]

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

Nawab Zada Asad iqbal edited comment on SOLR-11200 at 8/9/17 4:53 PM:
--

[~sarkaramr...@gmail.com] 
I just reviewed your patch, it looks good. For the name, what about 
`enableAutoIOThrottle` ? 

I will test it now and report if I see any issues. 

PS: I edited it after realizing that the long config name is initiating from 
LUCENE code. My previous suggestion was `enableIOThrottle`


was (Author: niqbal):
[~sarkaramr...@gmail.com] 
I just reviewed your patch, it looks good. For the name, what about 
`enableIOThrottle` ? The word `Auto` does not seem necessary. 

I will test it now and report if I see any issues. 

> provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
> ---
>
> Key: SOLR-11200
> URL: https://issues.apache.org/jira/browse/SOLR-11200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
> Attachments: SOLR-11200.patch, SOLR-11200.patch
>
>
> This config can be useful while bulk indexing. Lucene introduced it 
> https://issues.apache.org/jira/browse/LUCENE-6119 . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 106 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/106/

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.analytics.NoFacetCloudTest

Error Message:
org.apache.http.ParseException: Invalid content type: 

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.ParseException: Invalid content type: 
at __randomizedtesting.SeedInfo.seed([4188D01F7FAE0A7D]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:523)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.analytics.AbstractAnalyticsStatsCloudTest.setupCluster(AbstractAnalyticsStatsCloudTest.java:75)
at 
org.apache.solr.analytics.NoFacetCloudTest.populate(NoFacetCloudTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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.http.ParseException: Invalid content type: 
at org.apache.http.entity.ContentType.parse(ContentType.java:273)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
... 32 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
KeeperErrorCode = AuthFailed for /solr

Stack Trace:
org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
AuthFailed for /solr
at __randomizedtesting.SeedInfo.seed([440A9D9DD209B6A4]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:306)
at 

RE: Ready for JDK 9 ?

[Uwe Schindler]

Hi Rory,

Thank you for heads-up. I installed JDK 8 update 144 and Java 9 build 181 a 
minute ago. Once the first runs have succeeded, I'll report back.

About the current state:
- Apache Lucene 6.6 and the coming Apache Lucene 7.0 is fully comliant to Java 
9 and works with "--illegal-access=deny", so the "kill switch" is not needed.
- Apache Solr 6.6 and Apache Solr 7.0 work (Java wise), but the startup (shell) 
scripts don't detect the Java version correctly. I think a fix is in the make 
(for Windows and Linux). But if you ignore the startup scripts and do it 
yourself, it works. We applied some fixes for third party libraries that don't 
work correctly (e.g. Hadoop in the version we use).

Older Solr and Lucene versions may still have problems, as the Module system 
changed some internal APIs we need for unmapping files, but generally they 
should work, but not everything might be with best performance (e.g. it chooses 
slow NIOFSDirectory instead on memory mapping).

We currently do not support Lucene with Automodules, so you *have* to use 
Lucene on classpath. The reason is that the JAR files share same packages. So 
you cannot make modules out of Lucene or Solr. We may support this in later 
versions, but that's not an important reason for us. You can still combine all 
of Lucene and Solr and make one huge "Uber Module" out of it (and that's what I 
personally recommend), but that's up to the user.

Uwe

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

> -Original Message-
> From: Rory O'Donnell [mailto:rory.odonn...@oracle.com]
> Sent: Tuesday, August 8, 2017 12:04 PM
> To: Dawid Weiss ; Uwe Schindler
> 
> Cc: rory.odonn...@oracle.com; Dalibor Topic ;
> Balchandra Vaidya ; Muneer Kolarkunnu
> ; dev@lucene.apache.org
> Subject: Ready for JDK 9 ?
> 
> 
> Hi Uwe & Dawid,
> 
> Thank you very much for all your testing of JDK 9 during its
> development! Such contributions have significantly helped shape and
> improve JDK 9.
> 
> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
> would like to ask if your project can be considered to be 'ready for JDK
> 9', or if there are any remaining show stopper issues which you've
> encountered when testing with the JDK 9 release candidate.
> 
> JDK 9  b181 is available at http://jdk.java.net/9/
> 
> If you have a public web page, mailing list post, or even a tweet
> announcing you project's readiness for JDK 9, I'd love to add the URL to
> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
> 
> 
> Looking forward to hearing from you,
> Rory
> 
> [1] http://openjdk.java.net/projects/jdk9/
> 
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
> 
> 
> -
> 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-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle

[Nawab Zada Asad iqbal (JIRA)]

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

Nawab Zada Asad iqbal commented on SOLR-11200:
--

[~sarkaramr...@gmail.com]
which branch are you working from 6.6 or 7? 
I am getting an error while applying the patch. 

> provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
> ---
>
> Key: SOLR-11200
> URL: https://issues.apache.org/jira/browse/SOLR-11200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
> Attachments: SOLR-11200.patch, SOLR-11200.patch
>
>
> This config can be useful while bulk indexing. Lucene introduced it 
> https://issues.apache.org/jira/browse/LUCENE-6119 . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle

[Nawab Zada Asad iqbal (JIRA)]

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

Nawab Zada Asad iqbal commented on SOLR-11200:
--

[~sarkaramr...@gmail.com] 
I just reviewed your patch, it looks good. For the name, what about 
`enableIOThrottle` ? The word `Auto` does not seem necessary. 

I will test it now and report if I see any issues. 

> provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
> ---
>
> Key: SOLR-11200
> URL: https://issues.apache.org/jira/browse/SOLR-11200
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Nawab Zada Asad iqbal
>Priority: Minor
> Attachments: SOLR-11200.patch, SOLR-11200.patch
>
>
> This config can be useful while bulk indexing. Lucene introduced it 
> https://issues.apache.org/jira/browse/LUCENE-6119 . 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testForwarding

Error Message:
Error from server at http://127.0.0.1:53980/solr: KeeperErrorCode = Session 
expired for /overseer/collection-queue-work/qnr-

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:53980/solr: KeeperErrorCode = Session expired 
for /overseer/collection-queue-work/qnr-
at 
__randomizedtesting.SeedInfo.seed([CD0CAEA214D512FA:2C8AC75C09E3F413]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
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:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.create1ShardCollection(TestSolrCloudWithSecureImpersonation.java:185)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testForwarding(TestSolrCloudWithSecureImpersonation.java:342)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

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

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


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([2656ADCC0CFAF6DA:85AC03698B121C7F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:167)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Updated] (SOLR-11144) Analytics Component Documentation

[Houston Putman (JIRA)]

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

Houston Putman updated SOLR-11144:
--
Affects Version/s: (was: 7.0)

> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11217) Mathematical notation not supported in Solr Ref Guide

[Houston Putman (JIRA)]

Houston Putman created SOLR-11217:
-

 Summary: Mathematical notation not supported in Solr Ref Guide
 Key: SOLR-11217
 URL: https://issues.apache.org/jira/browse/SOLR-11217
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Houston Putman
Priority: Minor


The template used to build the Solr Ref Guide from the asciidoctor pages 
removes the needed javascript for mathematical notation. 

When building the webpage, asciidoctor puts a tag like the one below at the 
bottom of the html

{code:html}

{code}

and some other tags as well.

However these are not included in the sections that are inserted into the 
template, so they are left out and the mathematical notation is not converted 
to MathJax that can be viewed in a browser.

This can be tested by adding any stem notation in an asciidoctor solr-ref-page, 
such as the following text:

{code}
asciimath:[sqrt(4) = 2].
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10032:


Thanks! It actually ended up being a ton of work. It wasn't so bad just to 
stitch something together for Solr with me to fill in gaps, but to make it 
generic for any project using docker, to allow it to have tests (docker within 
docker!), to allow you to point it at 10 freshly provisioned machines with no 
setup on your part, to make it easy to debug and add new project support 
easily, etc, was actually many, many, many hours of effort. Still some polish 
and minor things to do, but very happy it's ready to start pushing out reports 
regularly now.

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 7.0, master (8.0)
>
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf, Lucene-Solr Master Test Beasults 
> 02-08-2017-6696eafaae18948c2891ce758c7a2ec09873dab8 Level Medium+- Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02-14-2017- Level Medium+-a1f114f70f3800292c25be08213edf39b3e37f6a Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02%2F17%2F2017-19c8ec2bf1882bed1bb34d0b55198d03f2018838 Level Hard Running 
> 100 iterations, 12 at a time, 8 cores.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.
> Reports:
> https://drive.google.com/drive/folders/0ByYyjsrbz7-qa2dOaU1UZDdRVzg?usp=sharing
> 01/24/2017 - 
> https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
> 02/01/2017 - 
> https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
> 02/08/2017 - 
> https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
> 02/14/2017 - 
> https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing
> 02/17/2017 - 
> https://docs.google.com/spreadsheets/d/1LEPvXbsoHtKfIcZCJZ3_P6OHp7S5g2HP2OJgU6B2sAg/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11061) Add a spins metric for all directory paths

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11061:


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

SOLR-11061: Fix incorrect metric path.


> Add a spins metric for all directory paths
> --
>
> Key: SOLR-11061
> URL: https://issues.apache.org/jira/browse/SOLR-11061
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11061.patch
>
>
> See org.apache.lucene.util.IOUtils.spins. It currently only works for linux 
> and is used by ConcurrentMergeScheduler to set defaults for maxThreadCount 
> and maxMergeCount.
> We should expose this as a metric for solr.data.home and each core's data 
> dir. One thing to note is that the CMS overrides the value detected by the 
> spins method using {{lucene.cms.override_spins}} system property. This 
> property is supposed to be for tests but if it is set then the metrics API 
> should also take that into account.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11061) Add a spins metric for all directory paths

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11061:


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

SOLR-11061: Fix incorrect metric path.


> Add a spins metric for all directory paths
> --
>
> Key: SOLR-11061
> URL: https://issues.apache.org/jira/browse/SOLR-11061
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11061.patch
>
>
> See org.apache.lucene.util.IOUtils.spins. It currently only works for linux 
> and is used by ConcurrentMergeScheduler to set defaults for maxThreadCount 
> and maxMergeCount.
> We should expose this as a metric for solr.data.home and each core's data 
> dir. One thing to note is that the CMS overrides the value detected by the 
> spins method using {{lucene.cms.override_spins}} system property. This 
> property is supposed to be for tests but if it is set then the metrics API 
> should also take that into account.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
KeeperErrorCode = AuthFailed for /solr

Stack Trace:
org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
AuthFailed for /solr
at __randomizedtesting.SeedInfo.seed([2F199689F10BCB56]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:306)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:512)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:467)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:454)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:441)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:233)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth.setupClass(TestZkAclsWithHadoopAuth.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth: 1) 
Thread[id=6639, name=Thread-1242, state=WAITING, 
group=TGRP-TestZkAclsWithHadoopAuth] at java.lang.Object.wait(Native 
Method) at java.lang.Thread.join(Thread.java:1252) at 
java.lang.Thread.join(Thread.java:1326) at 
org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:297)
 at 
org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:309)
 at org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:490)
2) Thread[id=6643, name=ProcessThread(sid:0 cport:42672):, state=WAITING, 
group=TGRP-TestZkAclsWithHadoopAuth] at sun.misc.Unsafe.park(Native 
Method) at 

[JENKINS] Lucene-Solr-7.0-Linux (32bit/jdk1.8.0_144) - Build # 173 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/173/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
KeeperErrorCode = AuthFailed for /solr

Stack Trace:
org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
AuthFailed for /solr
at __randomizedtesting.SeedInfo.seed([9BDCE853B68E8258]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:306)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:512)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:467)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:454)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:441)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:233)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth.setupClass(TestZkAclsWithHadoopAuth.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth: 1) 
Thread[id=9435, name=Thread-2455, state=WAITING, 
group=TGRP-TestZkAclsWithHadoopAuth] at java.lang.Object.wait(Native 
Method) at java.lang.Thread.join(Thread.java:1252) at 
java.lang.Thread.join(Thread.java:1326) at 
org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:297)
 at 
org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:309)
 at org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:490)
2) Thread[id=9439, name=ProcessThread(sid:0 cport:43009):, state=WAITING, 
group=TGRP-TestZkAclsWithHadoopAuth] 

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10032:
---

This is excellent, thanks for all your hard work here!

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 7.0, master (8.0)
>
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf, Lucene-Solr Master Test Beasults 
> 02-08-2017-6696eafaae18948c2891ce758c7a2ec09873dab8 Level Medium+- Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02-14-2017- Level Medium+-a1f114f70f3800292c25be08213edf39b3e37f6a Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02%2F17%2F2017-19c8ec2bf1882bed1bb34d0b55198d03f2018838 Level Hard Running 
> 100 iterations, 12 at a time, 8 cores.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.
> Reports:
> https://drive.google.com/drive/folders/0ByYyjsrbz7-qa2dOaU1UZDdRVzg?usp=sharing
> 01/24/2017 - 
> https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
> 02/01/2017 - 
> https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
> 02/08/2017 - 
> https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
> 02/14/2017 - 
> https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing
> 02/17/2017 - 
> https://docs.google.com/spreadsheets/d/1LEPvXbsoHtKfIcZCJZ3_P6OHp7S5g2HP2OJgU6B2sAg/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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_141) - Build # 230 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/230/
Java: 64bit/jdk1.8.0_141 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
KeeperErrorCode = AuthFailed for /solr

Stack Trace:
org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
AuthFailed for /solr
at __randomizedtesting.SeedInfo.seed([F90A02903FB99AA7]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:306)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:512)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:467)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:454)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:441)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:233)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth.setupClass(TestZkAclsWithHadoopAuth.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth: 1) 
Thread[id=13789, 
name=SUITE-TestZkAclsWithHadoopAuth-seed#[F90A02903FB99AA7]-worker-EventThread, 
state=WAITING, group=TGRP-TestZkAclsWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)
2) Thread[id=13784, 

[jira] [Commented] (SOLR-11199) Support OR queries in the Payload Score Parser

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-11199:
-

Nice work Varun!   Both `sum` and `phrase`/`or` - handy improvements!

> Support OR queries in the Payload Score Parser 
> ---
>
> Key: SOLR-11199
> URL: https://issues.apache.org/jira/browse/SOLR-11199
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11199.patch, SOLR-11199.patch
>
>
> PayloadScoreQParserPlugin always creates a SpanNearQuery. 
> In my use-case I want to be able to do an OR query and then use a sum 
> function to sum up all the scores.
> So if the PayloadScoreQParserPlugin supported an operator param which could 
> be used to pick between phrase searches ( the default currently ) OR and ANDs 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10032:


Those are special codes to order and identify tests with annotations.

So if a test is ignored, it's not run at all and gets a 122 or whatever. If 
it's @BadApple and fails 100%, it gets a 112, if it's @AwaitFix and fails 100% 
it gets a 113. So those 100% fails are basically expected. If it is 100%, it's 
a test that won't pass and doesn't have one of these annotations, so really bad.

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 7.0, master (8.0)
>
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf, Lucene-Solr Master Test Beasults 
> 02-08-2017-6696eafaae18948c2891ce758c7a2ec09873dab8 Level Medium+- Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02-14-2017- Level Medium+-a1f114f70f3800292c25be08213edf39b3e37f6a Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02%2F17%2F2017-19c8ec2bf1882bed1bb34d0b55198d03f2018838 Level Hard Running 
> 100 iterations, 12 at a time, 8 cores.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.
> Reports:
> https://drive.google.com/drive/folders/0ByYyjsrbz7-qa2dOaU1UZDdRVzg?usp=sharing
> 01/24/2017 - 
> https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
> 02/01/2017 - 
> https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
> 02/08/2017 - 
> https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
> 02/14/2017 - 
> https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing
> 02/17/2017 - 
> https://docs.google.com/spreadsheets/d/1LEPvXbsoHtKfIcZCJZ3_P6OHp7S5g2HP2OJgU6B2sAg/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11061) Add a spins metric for all directory paths

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11061:


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

SOLR-11061: Add a spins metric for data directory paths.


> Add a spins metric for all directory paths
> --
>
> Key: SOLR-11061
> URL: https://issues.apache.org/jira/browse/SOLR-11061
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11061.patch
>
>
> See org.apache.lucene.util.IOUtils.spins. It currently only works for linux 
> and is used by ConcurrentMergeScheduler to set defaults for maxThreadCount 
> and maxMergeCount.
> We should expose this as a metric for solr.data.home and each core's data 
> dir. One thing to note is that the CMS overrides the value detected by the 
> spins method using {{lucene.cms.override_spins}} system property. This 
> property is supposed to be for tests but if it is set then the metrics API 
> should also take that into account.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11061) Add a spins metric for all directory paths

[Andrzej Bialecki (JIRA)]

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

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

> Add a spins metric for all directory paths
> --
>
> Key: SOLR-11061
> URL: https://issues.apache.org/jira/browse/SOLR-11061
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11061.patch
>
>
> See org.apache.lucene.util.IOUtils.spins. It currently only works for linux 
> and is used by ConcurrentMergeScheduler to set defaults for maxThreadCount 
> and maxMergeCount.
> We should expose this as a metric for solr.data.home and each core's data 
> dir. One thing to note is that the CMS overrides the value detected by the 
> spins method using {{lucene.cms.override_spins}} system property. This 
> property is supposed to be for tests but if it is set then the metrics API 
> should also take that into account.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11061) Add a spins metric for all directory paths

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-11061:
-
Fix Version/s: master (8.0)

> Add a spins metric for all directory paths
> --
>
> Key: SOLR-11061
> URL: https://issues.apache.org/jira/browse/SOLR-11061
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11061.patch
>
>
> See org.apache.lucene.util.IOUtils.spins. It currently only works for linux 
> and is used by ConcurrentMergeScheduler to set defaults for maxThreadCount 
> and maxMergeCount.
> We should expose this as a metric for solr.data.home and each core's data 
> dir. One thing to note is that the CMS overrides the value detected by the 
> spins method using {{lucene.cms.override_spins}} system property. This 
> property is supposed to be for tests but if it is set then the metrics API 
> should also take that into account.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11061) Add a spins metric for all directory paths

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11061:


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

SOLR-11061: Add a spins metric for data directory paths.


> Add a spins metric for all directory paths
> --
>
> Key: SOLR-11061
> URL: https://issues.apache.org/jira/browse/SOLR-11061
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: 7.1
>
> Attachments: SOLR-11061.patch
>
>
> See org.apache.lucene.util.IOUtils.spins. It currently only works for linux 
> and is used by ConcurrentMergeScheduler to set defaults for maxThreadCount 
> and maxMergeCount.
> We should expose this as a metric for solr.data.home and each core's data 
> dir. One thing to note is that the CMS overrides the value detected by the 
> spins method using {{lucene.cms.override_spins}} system property. This 
> property is supposed to be for tests but if it is set then the metrics API 
> should also take that into account.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 105 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/105/

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
KeeperErrorCode = AuthFailed for /solr

Stack Trace:
org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
AuthFailed for /solr
at __randomizedtesting.SeedInfo.seed([206B883F6041D1BE]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:306)
at 
org.apache.solr.common.cloud.SolrZkClient$4.execute(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:303)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:512)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:467)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:454)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:441)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:233)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth.setupClass(TestZkAclsWithHadoopAuth.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth: 1) 
Thread[id=23348, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, 
group=TGRP-TestZkAclsWithHadoopAuth] at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:173)
 at java.lang.Thread.run(Thread.java:748)2) Thread[id=23349, 
name=SessionTracker, state=TIMED_WAITING, 

[jira] [Commented] (SOLR-10032) Create report to assess Solr test quality at a commit point.

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10032:
--

[~markrmil...@gmail.com] - This is really great, thank you.

I have one question, out of curiosity: Why do a few tests show up as failing 
more than 100% of the time?

> Create report to assess Solr test quality at a commit point.
> 
>
> Key: SOLR-10032
> URL: https://issues.apache.org/jira/browse/SOLR-10032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 7.0, master (8.0)
>
> Attachments: Lucene-Solr Master Test Beast Results 
> 01-24-2017-9899cbd031dc3fc37a384b1f9e2b379e90a9a3a6 Level Medium- Running 30 
> iterations, 12 at a time .pdf, Lucene-Solr Master Test Beasults 
> 02-01-2017-bbc455de195c83d9f807980b510fa46018f33b1b Level Medium- Running 30 
> iterations, 10 at a time.pdf, Lucene-Solr Master Test Beasults 
> 02-08-2017-6696eafaae18948c2891ce758c7a2ec09873dab8 Level Medium+- Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02-14-2017- Level Medium+-a1f114f70f3800292c25be08213edf39b3e37f6a Running 30 
> iterations, 10 at a time, 8 cores.pdf, Lucene-Solr Master Test Beasults 
> 02%2F17%2F2017-19c8ec2bf1882bed1bb34d0b55198d03f2018838 Level Hard Running 
> 100 iterations, 12 at a time, 8 cores.pdf
>
>
> We have many Jenkins instances blasting tests, some official, some policeman, 
> I and others have or had their own, and the email trail proves the power of 
> the Jenkins cluster to find test fails.
> However, I still have a very hard time with some basic questions:
> what tests are flakey right now? which test fails actually affect devs most? 
> did I break it? was that test already flakey? is that test still flakey? what 
> are our worst tests right now? is that test getting better or worse?
> We really need a way to see exactly what tests are the problem, not because 
> of OS or environmental issues, but more basic test quality issues. Which 
> tests are flakey and how flakey are they at any point in time.
> Reports:
> https://drive.google.com/drive/folders/0ByYyjsrbz7-qa2dOaU1UZDdRVzg?usp=sharing
> 01/24/2017 - 
> https://docs.google.com/spreadsheets/d/1JySta2j2s7A_p16wA1UO-l6c4GsUHBIb4FONS2EzW9k/edit?usp=sharing
> 02/01/2017 - 
> https://docs.google.com/spreadsheets/d/1FndoyHmihaOVL2o_Zns5alpNdAJlNsEwQVoJ4XDWj3c/edit?usp=sharing
> 02/08/2017 - 
> https://docs.google.com/spreadsheets/d/1N6RxH4Edd7ldRIaVfin0si-uSLGyowQi8-7mcux27S0/edit?usp=sharing
> 02/14/2017 - 
> https://docs.google.com/spreadsheets/d/1eZ9_ds_0XyqsKKp8xkmESrcMZRP85jTxSKkNwgtcUn0/edit?usp=sharing
> 02/17/2017 - 
> https://docs.google.com/spreadsheets/d/1LEPvXbsoHtKfIcZCJZ3_P6OHp7S5g2HP2OJgU6B2sAg/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteCollection

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([FBAD443757FF6F3C:FC78457C706B0A31]: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.CollectionsAPISolrJTest.testCreateAndDeleteCollection(CollectionsAPISolrJTest.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestZkAclsWithHadoopAuth

Error Message:
KeeperErrorCode = AuthFailed for /solr

Stack Trace:
org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
AuthFailed for /solr

[jira] [Commented] (LUCENE-7923) Remove FST.Arc.node field (not used anywhere)

[ASF subversion and git services (JIRA)]

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

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

Commit bd94c62a88b93db84a8378c9a80ab0b2886e41e5 in lucene-solr's branch 
refs/heads/branch_7_0 from [~dawid.weiss]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bd94c62 ]

LUCENE-7923: Removed FST.Arc.node field (unused).


> Remove FST.Arc.node field (not used anywhere)
> -
>
> Key: LUCENE-7923
> URL: https://issues.apache.org/jira/browse/LUCENE-7923
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.0
>
> Attachments: LUCENE-7923.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7923) Remove FST.Arc.node field (not used anywhere)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7923: Removed FST.Arc.node field (unused).


> Remove FST.Arc.node field (not used anywhere)
> -
>
> Key: LUCENE-7923
> URL: https://issues.apache.org/jira/browse/LUCENE-7923
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.0
>
> Attachments: LUCENE-7923.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7923) Remove FST.Arc.node field (not used anywhere)

[ASF subversion and git services (JIRA)]

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

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

Commit 5a36775d6517cbb36429981ccf4eb923dc1c7b33 in lucene-solr's branch 
refs/heads/master from [~dawid.weiss]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5a36775 ]

LUCENE-7923: Removed FST.Arc.node field (unused).


> Remove FST.Arc.node field (not used anywhere)
> -
>
> Key: LUCENE-7923
> URL: https://issues.apache.org/jira/browse/LUCENE-7923
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.0
>
> Attachments: LUCENE-7923.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7923) Remove FST.Arc.node field (not used anywhere)

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved LUCENE-7923.
-
Resolution: Fixed

> Remove FST.Arc.node field (not used anywhere)
> -
>
> Key: LUCENE-7923
> URL: https://issues.apache.org/jira/browse/LUCENE-7923
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.0
>
> Attachments: LUCENE-7923.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7923) Remove FST.Arc.node field (not used anywhere)

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated LUCENE-7923:

Attachment: LUCENE-7923.patch

> Remove FST.Arc.node field (not used anywhere)
> -
>
> Key: LUCENE-7923
> URL: https://issues.apache.org/jira/browse/LUCENE-7923
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.0
>
> Attachments: LUCENE-7923.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-7923) Remove FST.Arc.node field (not used anywhere)

[Dawid Weiss (JIRA)]

Dawid Weiss created LUCENE-7923:
---

 Summary: Remove FST.Arc.node field (not used anywhere)
 Key: LUCENE-7923
 URL: https://issues.apache.org/jira/browse/LUCENE-7923
 Project: Lucene - Core
  Issue Type: Task
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: 7.0






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (LUCENE-7922) Remove packed FST support?

[Dawid Weiss (JIRA)]

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

Dawid Weiss closed LUCENE-7922.
---

> Remove packed FST support?
> --
>
> Key: LUCENE-7922
> URL: https://issues.apache.org/jira/browse/LUCENE-7922
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
> Attachments: node.patch
>
>
> I've been looking at the FST code we have today. Complex to read, even more 
> complex to modify. I think it could benefit if we cleaned it up a bit (there 
> are a few issues out there already that mention this).
> The first baby step would be to remove the "packed" representation of FSTs -- 
> I searched the codebase and I don't see a single place where {{pack}} would 
> actually be {{true}}. The overhead associated with node packing seems to be 
> not worth it in practice (since most FSTs are already fairly small).
> It'd be a breaking API change, but it's probably something worth undertaking 
> for 7.0, unless I'm missing some use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7922) Remove packed FST support?

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated LUCENE-7922:

Attachment: node.patch

Didn't run tests, but I don't think it'll cause any harm to remove it. 

> Remove packed FST support?
> --
>
> Key: LUCENE-7922
> URL: https://issues.apache.org/jira/browse/LUCENE-7922
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
> Attachments: node.patch
>
>
> I've been looking at the FST code we have today. Complex to read, even more 
> complex to modify. I think it could benefit if we cleaned it up a bit (there 
> are a few issues out there already that mention this).
> The first baby step would be to remove the "packed" representation of FSTs -- 
> I searched the codebase and I don't see a single place where {{pack}} would 
> actually be {{true}}. The overhead associated with node packing seems to be 
> not worth it in practice (since most FSTs are already fairly small).
> It'd be a breaking API change, but it's probably something worth undertaking 
> for 7.0, unless I'm missing some use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7922) Remove packed FST support?

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7922:
-

I'd love to. :) I don't have much time these days, unfortunately. 

But wait. I do have a contribution: we can remove the 'node' field which isn't 
used anywhere. :)

> Remove packed FST support?
> --
>
> Key: LUCENE-7922
> URL: https://issues.apache.org/jira/browse/LUCENE-7922
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
> Attachments: node.patch
>
>
> I've been looking at the FST code we have today. Complex to read, even more 
> complex to modify. I think it could benefit if we cleaned it up a bit (there 
> are a few issues out there already that mention this).
> The first baby step would be to remove the "packed" representation of FSTs -- 
> I searched the codebase and I don't see a single place where {{pack}} would 
> actually be {{true}}. The overhead associated with node packing seems to be 
> not worth it in practice (since most FSTs are already fairly small).
> It'd be a breaking API change, but it's probably something worth undertaking 
> for 7.0, unless I'm missing some use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7922) Remove packed FST support?

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7922:


But please keep looking for simplifications!

> Remove packed FST support?
> --
>
> Key: LUCENE-7922
> URL: https://issues.apache.org/jira/browse/LUCENE-7922
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>
> I've been looking at the FST code we have today. Complex to read, even more 
> complex to modify. I think it could benefit if we cleaned it up a bit (there 
> are a few issues out there already that mention this).
> The first baby step would be to remove the "packed" representation of FSTs -- 
> I searched the codebase and I don't see a single place where {{pack}} would 
> actually be {{true}}. The overhead associated with node packing seems to be 
> not worth it in practice (since most FSTs are already fairly small).
> It'd be a breaking API change, but it's probably something worth undertaking 
> for 7.0, unless I'm missing some use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7922) Remove packed FST support?

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved LUCENE-7922.
-
   Resolution: Duplicate
Fix Version/s: (was: 7.0)

Argh. Sorry, duplicate and already done. I was looking at 6.x branch.

> Remove packed FST support?
> --
>
> Key: LUCENE-7922
> URL: https://issues.apache.org/jira/browse/LUCENE-7922
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>
> I've been looking at the FST code we have today. Complex to read, even more 
> complex to modify. I think it could benefit if we cleaned it up a bit (there 
> are a few issues out there already that mention this).
> The first baby step would be to remove the "packed" representation of FSTs -- 
> I searched the codebase and I don't see a single place where {{pack}} would 
> actually be {{true}}. The overhead associated with node packing seems to be 
> not worth it in practice (since most FSTs are already fairly small).
> It'd be a breaking API change, but it's probably something worth undertaking 
> for 7.0, unless I'm missing some use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-7922) Remove packed FST support?

[Dawid Weiss (JIRA)]

Dawid Weiss created LUCENE-7922:
---

 Summary: Remove packed FST support?
 Key: LUCENE-7922
 URL: https://issues.apache.org/jira/browse/LUCENE-7922
 Project: Lucene - Core
  Issue Type: Task
Reporter: Dawid Weiss
Assignee: Dawid Weiss
 Fix For: 7.0


I've been looking at the FST code we have today. Complex to read, even more 
complex to modify. I think it could benefit if we cleaned it up a bit (there 
are a few issues out there already that mention this).

The first baby step would be to remove the "packed" representation of FSTs -- I 
searched the codebase and I don't see a single place where {{pack}} would 
actually be {{true}}. The overhead associated with node packing seems to be not 
worth it in practice (since most FSTs are already fairly small).

It'd be a breaking API change, but it's probably something worth undertaking 
for 7.0, unless I'm missing some use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10126) PeerSyncReplicationTest is a flakey test.

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-10126:
--

Thanks for explaining. I see that you have created a follow-up issue to fix the 
root cause. I have linked SOLR-11216 to this issue.

> PeerSyncReplicationTest is a flakey test.
> -
>
> Key: SOLR-10126
> URL: https://issues.apache.org/jira/browse/SOLR-10126
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
> Attachments: faillogs.tar.gz, SOLR-10126.patch
>
>
> Could be related to SOLR-9555, but I will see what else pops up under 
> beasting.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11090) add Replica.getProperty accessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11090:


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

SOLR-11090: Add Replica.getProperty accessor.


> add Replica.getProperty accessor
> 
>
> Key: SOLR-11090
> URL: https://issues.apache.org/jira/browse/SOLR-11090
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11090.patch, SOLR-11090.patch
>
>
> {code}
> ?action=ADDREPLICAPROP&...=propertyName=value
> {code}
> and
> {code}
> ?action=ADDREPLICAPROP&...=property.propertyName=value
> {code}
> are equivalent forms for use of the 
> [ADDREPLICAPROP|https://lucene.apache.org/solr/guide/6_6/collections-api.html]
>  collection API action.
> At present within the code only the generic getStr i.e.
> {code}
> replica.getStr("property.propertyName")
> {code}
> is available to obtain a replica property.
> This ticket proposes a {{replica.getProperty(String)}} accessor which 
> supports both equivalent forms i.e.
> {code}
> replica.getProperty("propertyName")
> {code}
> and
> {code}
> replica.getProperty("property.propertyName")
> {code}
> to be used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11090) add Replica.getProperty accessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11090:


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

SOLR-11090: Add Replica.getProperty accessor.


> add Replica.getProperty accessor
> 
>
> Key: SOLR-11090
> URL: https://issues.apache.org/jira/browse/SOLR-11090
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11090.patch, SOLR-11090.patch
>
>
> {code}
> ?action=ADDREPLICAPROP&...=propertyName=value
> {code}
> and
> {code}
> ?action=ADDREPLICAPROP&...=property.propertyName=value
> {code}
> are equivalent forms for use of the 
> [ADDREPLICAPROP|https://lucene.apache.org/solr/guide/6_6/collections-api.html]
>  collection API action.
> At present within the code only the generic getStr i.e.
> {code}
> replica.getStr("property.propertyName")
> {code}
> is available to obtain a replica property.
> This ticket proposes a {{replica.getProperty(String)}} accessor which 
> supports both equivalent forms i.e.
> {code}
> replica.getProperty("propertyName")
> {code}
> and
> {code}
> replica.getProperty("property.propertyName")
> {code}
> to be used.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11215) Make a metric accessible through a single param

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-11215:
-
Fix Version/s: 7.2

> Make a metric accessible through a single param
> ---
>
> Key: SOLR-11215
> URL: https://issues.apache.org/jira/browse/SOLR-11215
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Andrzej Bialecki 
> Fix For: 7.2
>
>
> example
> {code}
> /admin/metrics?key=solr.jvm:classes.loaded=solr.jvm:system.properties:java.specification.version
> {code}
> The above request must return just the two items in their corresponding path



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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