[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1243 - Still unstable

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.RestartWhileUpdatingTest.test

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 320 
seconds
at 
__randomizedtesting.SeedInfo.seed([FF890383E4B2199:87ACAFE290B74C61]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:862)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1418)
at 
org.apache.solr.cloud.RestartWhileUpdatingTest.test(RestartWhileUpdatingTest.java:144)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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-9994) Add support for CollapseQParser with PointFields

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9994:


At first I was confused what Points has to do with CollapseQParser since 
collapsing should be on DocValues, not on an index (be it Terms or Points) but 
now I understand that it's _still_ DocValues, it's just that the collapse 
doesn't know about these new field types.  I wonder if these features that need 
to detect the DocValues type might be improved by introducing some method on 
FieldType that returns the Int/Long/Float/Double interpretation of the numeric 
DocValues, assuming the field even has numeric DocValues?  The result would be 
reducing instanceof checks (usually a good thing) which also allows for more 
flexibility of user defined special numeric fields.  Heck you could even 
collapse on an enum field then.

> Add support for CollapseQParser with PointFields
> 
>
> Key: SOLR-9994
> URL: https://issues.apache.org/jira/browse/SOLR-9994
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9994.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

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

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([7C62D56C0E428263:F436EAB6A0BEEF9B]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1251)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:702)
at org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:122)
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:745)




Build Log:
[...truncated 11933 lines...]
   [junit4] Suite: org.apache.solr.cloud.RecoveryZkTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.RecoveryZkTest_7C62D56C0E428263-001/init-core-data-001
   

[jira] [Commented] (LUCENE-7699) Apply graph articulation points optimization to phrase graph queries

[Matt Weber (JIRA)]

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

Matt Weber commented on LUCENE-7699:


[~jim.ferenczi] [~mikemccand] What do you think?

> Apply graph articulation points optimization to phrase graph queries
> 
>
> Key: LUCENE-7699
> URL: https://issues.apache.org/jira/browse/LUCENE-7699
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Matt Weber
> Attachments: LUCENE-7699.patch
>
>
> Follow-up to LUCENE-7638 that applies the same articulation point logic to 
> graph phrases using span queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7699) Apply graph articulation points optimization to phrase graph queries

[Matt Weber (JIRA)]

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

Matt Weber updated LUCENE-7699:
---
Attachment: LUCENE-7699.patch

WIP

> Apply graph articulation points optimization to phrase graph queries
> 
>
> Key: LUCENE-7699
> URL: https://issues.apache.org/jira/browse/LUCENE-7699
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Matt Weber
> Attachments: LUCENE-7699.patch
>
>
> Follow-up to LUCENE-7638 that applies the same articulation point logic to 
> graph phrases using span queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7699) Apply graph articulation points optimization to phrase graph queries

[Matt Weber (JIRA)]

Matt Weber created LUCENE-7699:
--

 Summary: Apply graph articulation points optimization to phrase 
graph queries
 Key: LUCENE-7699
 URL: https://issues.apache.org/jira/browse/LUCENE-7699
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Matt Weber


Follow-up to LUCENE-7638 that applies the same articulation point logic to 
graph phrases using span queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10156) Add significantTerms Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10156:
---

Initial rough patch, no tests yet.

> Add significantTerms Streaming Expression
> -
>
> Key: SOLR-10156
> URL: https://issues.apache.org/jira/browse/SOLR-10156
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5
>
> Attachments: SOLR-10156.patch
>
>
> The significantTerms Streaming Expression will emit a set of terms from a 
> *text field* within a doc frequency range for a specific query. It will also 
> score the terms based on how many times the terms appear in the result set, 
> and how many times the terms appear in the corpus, and return the top N terms 
> based on this significance score.
> Syntax:
> {code}
> significantTerms(collection, 
>q="abc", 
>field="some_text_field", 
>minDocFreq="x", 
>maxDocFreq="y",
>limit="50")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10156) Add significantTerms Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10156:
--
Attachment: SOLR-10156.patch

> Add significantTerms Streaming Expression
> -
>
> Key: SOLR-10156
> URL: https://issues.apache.org/jira/browse/SOLR-10156
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5
>
> Attachments: SOLR-10156.patch
>
>
> The significantTerms Streaming Expression will emit a set of terms from a 
> *text field* within a doc frequency range for a specific query. It will also 
> score the terms based on how many times the terms appear in the result set, 
> and how many times the terms appear in the corpus, and return the top N terms 
> based on this significance score.
> Syntax:
> {code}
> significantTerms(collection, 
>q="abc", 
>field="some_text_field", 
>minDocFreq="x", 
>maxDocFreq="y",
>limit="50")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10175) replace @Ignore for TestAnalyticsQParserPlugin

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10175:


Commit 017b8a6e2852bcd423661ad457bb623f05bbbf5e in lucene-solr's branch 
refs/heads/branch_6x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=017b8a6 ]

SOLR-10175: Rename test so it doesn't match test glob pattern.


> replace @Ignore for TestAnalyticsQParserPlugin
> --
>
> Key: SOLR-10175
> URL: https://issues.apache.org/jira/browse/SOLR-10175
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> As per the latest SOLR-10032 report any tests marked @Ignore are not run and 
> included in the report as mission-failed. This ticket is to first mark the 
> test as @AwaitsFix and then to either use this ticket to fix it or to remove 
> the AwaitsFix tag if there is nothing to fix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_121) - Build # 2905 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2905/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 11157 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J1 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [72/696 (1!)] on J1 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 64719 lines...]


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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([2A25363D775B272A:A27109E7D9A74AD2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:159)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:620)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10175) replace @Ignore for TestAnalyticsQParserPlugin

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10175:


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

SOLR-10175: Rename test so it doesn't match test glob pattern.


> replace @Ignore for TestAnalyticsQParserPlugin
> --
>
> Key: SOLR-10175
> URL: https://issues.apache.org/jira/browse/SOLR-10175
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> As per the latest SOLR-10032 report any tests marked @Ignore are not run and 
> included in the report as mission-failed. This ticket is to first mark the 
> test as @AwaitsFix and then to either use this ticket to fix it or to remove 
> the AwaitsFix tag if there is nothing to fix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 11843 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J0 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [331/694 (1!)] on J0 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 63815 lines...]



-
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 (32bit/jdk-9-ea+155) - Build # 19013 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19013/
Java: 32bit/jdk-9-ea+155 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 11442 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J0 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [186/694 (1!)] on J0 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 53297 lines...]


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

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

[Policeman Jenkins Server]

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

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica2","base_url":"http://127.0.0.1:55976/t_u/ru","node_name":"127.0.0.1:55976_t_u%2Fru","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/31)={   
"replicationFactor":"3",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:55957/t_u/ru;,   
"node_name":"127.0.0.1:55957_t_u%2Fru",   "state":"down"}, 
"core_node2":{   "state":"down",   
"base_url":"http://127.0.0.1:55966/t_u/ru;,   
"core":"c8n_1x3_lf_shard1_replica3",   
"node_name":"127.0.0.1:55966_t_u%2Fru"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica2",   
"base_url":"http://127.0.0.1:55976/t_u/ru;,   
"node_name":"127.0.0.1:55976_t_u%2Fru",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica2","base_url":"http://127.0.0.1:55976/t_u/ru","node_name":"127.0.0.1:55976_t_u%2Fru","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/31)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:55957/t_u/ru;,
  "node_name":"127.0.0.1:55957_t_u%2Fru",
  "state":"down"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:55966/t_u/ru;,
  "core":"c8n_1x3_lf_shard1_replica3",
  "node_name":"127.0.0.1:55966_t_u%2Fru"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:55976/t_u/ru;,
  "node_name":"127.0.0.1:55976_t_u%2Fru",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([E79E43B57CEC810D:6FCA7C6FD210ECF5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[JENKINS] Lucene-Solr-Tests-6.x - Build # 742 - Still Unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.OverseerRolesTest.testOverseerRole

Error Message:
Timed out waiting for overseer state change

Stack Trace:
java.lang.AssertionError: Timed out waiting for overseer state change
at 
__randomizedtesting.SeedInfo.seed([394E0DA61E1C14A5:D885F03225AF2274]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:62)
at 
org.apache.solr.cloud.OverseerRolesTest.testOverseerRole(OverseerRolesTest.java:140)
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:745)


FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 

[jira] [Comment Edited] (LUCENE-7638) Optimize graph query produced by QueryBuilder

[Matt Weber (JIRA)]

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

Matt Weber edited comment on LUCENE-7638 at 2/21/17 12:38 AM:
--

[~jim.ferenczi] [~mikemccand] Could we apply the same articulation points logic 
in analyzeGraphPhrase but generate span queries to essentially act like a 
phrase? 

{code}
SpanNear[
  SpanOr[
SpanNear[SpanTerm[new], SpanTerm[york]]
SpanTerm[ny]
  ],
  SpanTerm[city]
]
{code}



was (Author: mattweber):
[~jim.ferenczi] [~mikemccand] Could we apply the same articulation points logic 
in analyzeGraphPhrase but generate span queries to essentially act like a 
phrase? 

SpanNear[
  SpanOr[
SpanNear[SpanTerm[new], SpanTerm[york]]
SpanTerm[ny]
  ],
  SpanTerm[city]
]



> Optimize graph query produced by QueryBuilder
> -
>
> Key: LUCENE-7638
> URL: https://issues.apache.org/jira/browse/LUCENE-7638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7638.patch, LUCENE-7638.patch
>
>
> The QueryBuilder creates a graph query when the underlying TokenStream 
> contains token with PositionLengthAttribute greater than 1.
> These TokenStreams are in fact graphs (lattice to be more precise) where 
> synonyms can span on multiple terms. 
> Currently the graph query is built by visiting all the path of the graph 
> TokenStream. For instance if you have a synonym like "ny, new york" and you 
> search for "new york city", the query builder would produce two pathes:
> "new york city", "ny city"
> This can quickly explode when the number of multi terms synonyms increase. 
> The query "ny ny" for instance would produce 4 pathes and so on.
> For boolean queries with should or must clauses it should be more efficient 
> to build a boolean query that merges all the intersections in the graph. So 
> instead of "new york city", "ny city" we could produce:
> "+((+new +york) ny) +city"
> The attached patch is a proposal to do that instead of the all path solution.
> The patch transforms multi terms synonyms in graph query for each 
> intersection in the graph. This is not done in this patch but we could also 
> create a specialized query that gives equivalent scores to multi terms 
> synonyms like the SynonymQuery does for single term synonyms.
> For phrase query this patch does not change the current behavior but we could 
> also use the new method to create optimized graph SpanQuery.
> [~mattweber] I think this patch could optimize a lot of cases where multiple 
> muli-terms synonyms are present in a single request. Could you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7638) Optimize graph query produced by QueryBuilder

[Matt Weber (JIRA)]

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

Matt Weber commented on LUCENE-7638:


[~jim.ferenczi] [~mikemccand] Could we apply the same articulation points logic 
in analyzeGraphPhrase but generate span queries to essentially act like a 
phrase? 

SpanNear[
  SpanOr[
SpanNear[SpanTerm[new], SpanTerm[york]]
SpanTerm[ny]
  ],
  SpanTerm[city]
]



> Optimize graph query produced by QueryBuilder
> -
>
> Key: LUCENE-7638
> URL: https://issues.apache.org/jira/browse/LUCENE-7638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7638.patch, LUCENE-7638.patch
>
>
> The QueryBuilder creates a graph query when the underlying TokenStream 
> contains token with PositionLengthAttribute greater than 1.
> These TokenStreams are in fact graphs (lattice to be more precise) where 
> synonyms can span on multiple terms. 
> Currently the graph query is built by visiting all the path of the graph 
> TokenStream. For instance if you have a synonym like "ny, new york" and you 
> search for "new york city", the query builder would produce two pathes:
> "new york city", "ny city"
> This can quickly explode when the number of multi terms synonyms increase. 
> The query "ny ny" for instance would produce 4 pathes and so on.
> For boolean queries with should or must clauses it should be more efficient 
> to build a boolean query that merges all the intersections in the graph. So 
> instead of "new york city", "ny city" we could produce:
> "+((+new +york) ny) +city"
> The attached patch is a proposal to do that instead of the all path solution.
> The patch transforms multi terms synonyms in graph query for each 
> intersection in the graph. This is not done in this patch but we could also 
> create a specialized query that gives equivalent scores to multi terms 
> synonyms like the SynonymQuery does for single term synonyms.
> For phrase query this patch does not change the current behavior but we could 
> also use the new method to create optimized graph SpanQuery.
> [~mattweber] I think this patch could optimize a lot of cases where multiple 
> muli-terms synonyms are present in a single request. Could you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10179) DBQ should use a Occur.FILTER instead of Occur.MUST

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-10179:
---

 Summary: DBQ should use a Occur.FILTER instead of Occur.MUST
 Key: SOLR-10179
 URL: https://issues.apache.org/jira/browse/SOLR-10179
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya
Priority: Minor


In DUH2's getQuery() method, which is used to generate a BooleanQuery for the 
DBQ operations, the main deletion clause uses Occur.MUST. Since this query 
doesn't need any scoring, this clause is ultimately re-written to a 
Occur.FILTER (at BooleanQuery's rewriteNoScoring()). We can avoid this query 
rewrite if we use Occur.FILTER instead of Occur.MUST in the first place.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_121) - Build # 2904 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2904/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 11705 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J1 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [250/696 (1!)] on J1 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 64153 lines...]


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

[jira] [Updated] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-10178:

Description: 
TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
assert in-place updates.

Towards that, NoMergePolicy is best suited and working fine on master (by 
defining it using NoMergePolicyFactory).

This doesn't work with just the MergePolicy 
(systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
and doesn't have a constructor. Setting only a NoMergePolicyFactory 
(systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
NoMergePolicy[Factory].

Here's the corresponding test failure: 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/

Seems to me that SOLR-8668 needs to be backported to branch_6x for this test to 
work, or some other stopgap hack needs to be put in place to make it work 
before SOLR-8668 is backported. [~cpoerschke], WDYT?

  was:
TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
assert in-place updates.

Towards that, NoMergePolicy is best suited and working fine on master (by 
defining it using NoMergePolicyFactory).

This doesn't work with just the MergePolicy 
(systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
and doesn't have a constructor. Setting only a NoMergePolicyFactory 
(systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
NoMergePolicy[Factory].

Seems to me that SOLR-8668 needs to be backported to branch_6x for this test to 
work, or some other stopgap hack needs to be put in place to make it work 
before SOLR-8668 is backported. [~cpoerschke], WDYT?


> TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x
> ---
>
> Key: SOLR-10178
> URL: https://issues.apache.org/jira/browse/SOLR-10178
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
> assert in-place updates.
> Towards that, NoMergePolicy is best suited and working fine on master (by 
> defining it using NoMergePolicyFactory).
> This doesn't work with just the MergePolicy 
> (systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
> and doesn't have a constructor. Setting only a NoMergePolicyFactory 
> (systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
> falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
> NoMergePolicy[Factory].
> Here's the corresponding test failure: 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
> Seems to me that SOLR-8668 needs to be backported to branch_6x for this test 
> to work, or some other stopgap hack needs to be put in place to make it work 
> before SOLR-8668 is backported. [~cpoerschke], WDYT?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8668) Remove support for (in favour of )

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8668:


FYI, I ran into a MP vs MPF issue while backporting a test to branch_6x, 
SOLR-10178. Possibly related to this issue?

> Remove support for  (in favour of )
> 
>
> Key: SOLR-8668
> URL: https://issues.apache.org/jira/browse/SOLR-8668
> Project: Solr
>  Issue Type: Improvement
>Reporter: Shai Erera
>Priority: Blocker
> Fix For: master (7.0)
>
>
> Following SOLR-8621, we should remove support for {{}} (and 
> related {{}} and {{}}) in trunk/6x.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10178) TestInPlaceUpdatesDistrib unable to use NoMergePolicy[Factory] on branch_6x

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-10178:
---

 Summary: TestInPlaceUpdatesDistrib unable to use 
NoMergePolicy[Factory] on branch_6x
 Key: SOLR-10178
 URL: https://issues.apache.org/jira/browse/SOLR-10178
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya


TestInPlaceUpdatesDistrib depends on consistent segments to track docIds to 
assert in-place updates.

Towards that, NoMergePolicy is best suited and working fine on master (by 
defining it using NoMergePolicyFactory).

This doesn't work with just the MergePolicy 
(systemSetPropertySolrTestsMergePolicy()), since NoMergePolicy is a singleton 
and doesn't have a constructor. Setting only a NoMergePolicyFactory 
(systemSetPropertySolrTestsMergePolicyFactory()) seems to take no effect and 
falls back on RandomMergePolicyFactory. As a result, this test cannot use the 
NoMergePolicy[Factory].

Seems to me that SOLR-8668 needs to be backported to branch_6x for this test to 
work, or some other stopgap hack needs to be put in place to make it work 
before SOLR-8668 is backported. [~cpoerschke], WDYT?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.store.blockcache.BlockDirectoryTest.testRandomAccessWrites

Error Message:
Direct buffer memory

Stack Trace:
java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:693)
at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
at 
org.apache.solr.store.blockcache.BlockCache.(BlockCache.java:70)
at 
org.apache.solr.store.blockcache.BlockDirectoryTest.setUp(BlockDirectoryTest.java:119)
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$9.evaluate(RandomizedRunner.java:941)
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:745)


FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_121) - Build # 740 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/740/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseSerialGC

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2\data\tlog\tlog.001:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2\data\tlog\tlog.001:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2\data\tlog

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2\data

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard1_replica2

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2\data\tlog\tlog.001:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2\data\tlog\tlog.001:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2\data\tlog

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2\data

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node1\collection1_shard2_replica2

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

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node2\collection1_shard1_replica1\data\tlog\tlog.001:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_2284089434E82A9B-001\tempDir-001\node2\collection1_shard1_replica1\data\tlog\tlog.001:
 The process cannot access the file because it is being used by another 
process. 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19012/
Java: 32bit/jdk-9-ea+155 -client -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
'sanitycheck' results against client: 
org.apache.solr.client.solrj.impl.HttpSolrClient@1d6d138 (not leader) wrong 
[docid] for SolrDocument{id=5, 
id_field_copy_that_does_not_support_in_place_update_s=5, title_s=title5, 
id_i=5, inplace_updatable_float=101.0, _version_=1559893822808260608, 
inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0, [docid]=6798} expected:<7196> but 
was:<6798>

Stack Trace:
java.lang.AssertionError: 'sanitycheck' results against client: 
org.apache.solr.client.solrj.impl.HttpSolrClient@1d6d138 (not leader) wrong 
[docid] for SolrDocument{id=5, 
id_field_copy_that_does_not_support_in_place_update_s=5, title_s=title5, 
id_i=5, inplace_updatable_float=101.0, _version_=1559893822808260608, 
inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0, [docid]=6798} expected:<7196> but 
was:<6798>
at 
__randomizedtesting.SeedInfo.seed([FF94ACFBB5DBDADC:77C093211B27B724]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.assertDocIdsAndValuesInResults(TestInPlaceUpdatesDistrib.java:442)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.assertDocIdsAndValuesAgainstAllClients(TestInPlaceUpdatesDistrib.java:413)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.docValuesUpdateTest(TestInPlaceUpdatesDistrib.java:321)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:140)
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:543)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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 

[jira] [Commented] (SOLR-10177) Consolidate randomized usage of PointFields in schemas

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10177:
-

The crux of my suggestion was:
{quote}
 I think we should rename these two as: (a) "solr.tests.floatFieldType" as 
pfloat or float, when used on a per field basis, or (b) 
"solr.tests.floatClassName" as FloatPointField, when used in a fieldType 
definition.
{quote}

> Consolidate randomized usage of PointFields in schemas
> --
>
> Key: SOLR-10177
> URL: https://issues.apache.org/jira/browse/SOLR-10177
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> schema-inplace-updates.xml use per fieldType point fields randomization, 
> whereas other some schemas use per-field. However, the variable name is 
> similar and should be revisited and standardized across our tests.
> Discussions here 
> https://issues.apache.org/jira/browse/SOLR-5944?focusedCommentId=15875108=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875108.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10177) Consolidate randomized usage of PointFields in schemas

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-10177:

Description: 
schema-inplace-updates.xml use per fieldType point fields randomization, 
whereas other some schemas use per-field. However, the variable name is similar 
and should be revisited and standardized across our tests.

Discussions here 
https://issues.apache.org/jira/browse/SOLR-5944?focusedCommentId=15875108=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875108.

  was:
schema-inplace-updates.xml use per fieldType point fields randomization, 
whereas other some schemas use per-field. However, the variable name is similar 
and should be revisited and standardized across our tests.

Discussions here SOLR-5944.


> Consolidate randomized usage of PointFields in schemas
> --
>
> Key: SOLR-10177
> URL: https://issues.apache.org/jira/browse/SOLR-10177
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> schema-inplace-updates.xml use per fieldType point fields randomization, 
> whereas other some schemas use per-field. However, the variable name is 
> similar and should be revisited and standardized across our tests.
> Discussions here 
> https://issues.apache.org/jira/browse/SOLR-5944?focusedCommentId=15875108=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875108.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-5944 at 2/20/17 10:53 PM:
--

The other usages of were on a per field definition, whereas I wanted to use it 
on a per fieldType definition.

The other usages, e.g.
{code}

{code}
seemed like mis-named. "pfloat" here refers to a named fieldType definition, 
and not a "floatClass". Hence, I chose the other convention of 
"FloatPointField" being referred to as "solr.tests.floatClassName".

To standardize, I think we should rename these two as: (a) 
"solr.tests.floatFieldType" as pfloat or float, when used on a per field basis, 
or (b) "solr.tests.floatClassName" as FloatPointField, when used in a fieldType 
definition.

WDYT? Added SOLR-10177.


was (Author: ichattopadhyaya):
The other usages of were on a per field definition, whereas I wanted to use it 
on a per fieldType definition.

The other usages, e.g.
{code}

{code}
seemed like mis-named. "pfloat" here refers to a named fieldType definition, 
and not a "floatClass". Hence, I chose the other convention of 
"FloatPointField" being referred to as "solr.tests.floatClassName".

To standardize, I think we should rename these two as: (a) 
"solr.tests.floatFieldType" as pfloat or float, when used on a per field basis, 
or (b) "solr.tests.floatClassName" as FloatPointField, when used in a fieldType 
definition.

WDYT? [~varunthacker], can you please open a new issue (and link to SOLR-5944 
and SOLR-8396) to address this?

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 6.5, master (7.0)
>
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, master-vs-5944-regular-updates.png, 
> regular-vs-dv-updates.png, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10177) Consolidate randomized usage of PointFields in schemas

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-10177:
---

 Summary: Consolidate randomized usage of PointFields in schemas
 Key: SOLR-10177
 URL: https://issues.apache.org/jira/browse/SOLR-10177
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya


schema-inplace-updates.xml use per fieldType point fields randomization, 
whereas other some schemas use per-field. However, the variable name is similar 
and should be revisited and standardized across our tests.

Discussions here SOLR-5944.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-5944 at 2/20/17 10:50 PM:
--

The other usages of were on a per field definition, whereas I wanted to use it 
on a per fieldType definition.

The other usages, e.g.
{code}

{code}
seemed like mis-named. "pfloat" here refers to a named fieldType definition, 
and not a "floatClass". Hence, I chose the other convention of 
"FloatPointField" being referred to as "solr.tests.floatClassName".

To standardize, I think we should rename these two as: (a) 
"solr.tests.floatFieldType" as pfloat or float, when used on a per field basis, 
or (b) "solr.tests.floatClassName" as FloatPointField, when used in a fieldType 
definition.

WDYT? [~varunthacker], can you please open a new issue (and link to SOLR-5944 
and SOLR-8396) to address this?


was (Author: ichattopadhyaya):
The other usages of were on a per field definition, whereas I wanted to use it 
on a per fieldType definition.

The other usages, e.g.
{code}

{code}
seemed like mis-named. "pfloat" here refers to a named fieldType definition, 
and not a "floatClass". Hence, I chose the other convention of 
"FloatPointField" being referred to as "solr.tests.floatClassName".

To standardize, I think we should rename these two as: (a) 
"solr.tests.floatFieldType" as pfloat or float, when used on a per field basis, 
or (b) "solr.tests.floatClassName" as FloatPointField, when used in a fieldType 
definition.

WDYT?

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 6.5, master (7.0)
>
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, master-vs-5944-regular-updates.png, 
> regular-vs-dv-updates.png, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-5944:


The other usages of were on a per field definition, whereas I wanted to use it 
on a per fieldType definition.

The other usages, e.g.
{code}

{code}
seemed like mis-named. "pfloat" here refers to a named fieldType definition, 
and not a "floatClass". Hence, I chose the other convention of 
"FloatPointField" being referred to as "solr.tests.floatClassName".

To standardize, I think we should rename these two as: (a) 
"solr.tests.floatFieldType" as pfloat or float, when used on a per field basis, 
or (b) "solr.tests.floatClassName" as FloatPointField, when used in a fieldType 
definition.

WDYT?

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 6.5, master (7.0)
>
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, master-vs-5944-regular-updates.png, 
> regular-vs-dv-updates.png, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10175) replace @Ignore for TestAnalyticsQParserPlugin

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10175:
---

This is causing failures, e.g. from 
[https://builds.apache.org/job/Lucene-Solr-Tests-6.x/741/]:

{noformat}
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J1 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [628/696 (1!)] on J1 in 0.00s, 1 test, 1 error <<< 
FAILURES!
{noformat}

Looks to me like TestAnalyticsQParserPlugin is a test utility class, and the 
test runner thinks it should instead be a unit test suite.  Maybe it should 
just be renamed, e.g. to AnalyticsQParserTestPlugin OSLT so that the test 
runner's name glob doesn't match?

> replace @Ignore for TestAnalyticsQParserPlugin
> --
>
> Key: SOLR-10175
> URL: https://issues.apache.org/jira/browse/SOLR-10175
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> As per the latest SOLR-10032 report any tests marked @Ignore are not run and 
> included in the report as mission-failed. This ticket is to first mark the 
> test as @AwaitsFix and then to either use this ticket to fix it or to remove 
> the AwaitsFix tag if there is nothing to fix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7465) Add a PatternTokenizer that uses Lucene's RegExp implementation

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7465:


Another reproducing TestRandomChains master seed, from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19011/]:

{noformat}
   [junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
   [junit4]   2> TEST FAIL: useCharFilter=false text='Sy 
\ud98b\udc04\uff52\u0384\u942fP\u040a\u0004\u0455 |uh)a)mrB- '
   [junit4]   2> Exception from random analyzer: 
   [junit4]   2> charfilters=
   [junit4]   2>   
org.apache.lucene.analysis.charfilter.HTMLStripCharFilter(java.io.StringReader@29890127,
 [])
   [junit4]   2> tokenizer=
   [junit4]   2>   
org.apache.lucene.analysis.pattern.SimplePatternTokenizer(org.apache.lucene.util.automaton.Automaton@9bd88db)
   [junit4]   2> filters=
   [junit4]   2> offsetsAreCorrect=true
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRandomChains 
-Dtests.method=testRandomChainsWithLargeStrings -Dtests.seed=821B9B2715E2264F 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=el-GR 
-Dtests.timezone=America/Lima -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 0.15s J2 | 
TestRandomChains.testRandomChainsWithLargeStrings <<<
   [junit4]> Throwable #1: java.lang.AssertionError: finalOffset 
expected:<24> but was:<23>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([821B9B2715E2264F:E84024364CAC06BC]:0)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:293)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:308)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:312)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:843)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:642)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:540)
   [junit4]>at 
org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:880)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=true): {}, locale=el-GR, timezone=America/Lima
   [junit4]   2> NOTE: Linux 4.4.0-53-generic amd64/Oracle Corporation 
1.8.0_121 (64-bit)/cpus=12,threads=1,free=457314736,total=508952576
{noformat}

> Add a PatternTokenizer that uses Lucene's RegExp implementation
> ---
>
> Key: LUCENE-7465
> URL: https://issues.apache.org/jira/browse/LUCENE-7465
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7465.patch, LUCENE-7465.patch
>
>
> I think there are some nice benefits to a version of PatternTokenizer that 
> uses Lucene's RegExp impl instead of the JDK's:
>   * Lucene's RegExp is compiled to a DFA up front, so if a "too hard" RegExp 
> is attempted the user discovers it up front instead of later on when a 
> "lucky" document arrives
>   * It processes the incoming characters as a stream, only pulling 128 
> characters at a time, vs the existing {{PatternTokenizer}} which currently 
> reads the entire string up front (this has caused heap problems in the past)
>   * It should be fast.
> I named it {{SimplePatternTokenizer}}, and it still needs a factory and 
> improved tests, but I think it's otherwise close.
> It currently does not take a {{group}} parameter because Lucene's RegExps 
> don't yet implement sub group capture.  I think we could add that at some 
> point, but it's a bit tricky.
> This doesn't even have group=-1 support (like String.split) ... I think if we 
> did that we should maybe name it differently 
> ({{SimplePatternSplitTokenizer}}?).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 741 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 12934 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J1 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [628/696 (1!)] on J1 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 62876 lines...]



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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6407/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 12869 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J1 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [615/694 (1!)] on J1 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 62875 lines...]


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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_121) - Build # 2903 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2903/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 12953 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J0 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [627/696 (1!)] on J0 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 62900 lines...]


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

[jira] [Commented] (SOLR-10134) EmbeddedSolrServer does not support SchemaAPI

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-10134:
-

[~robert_alex], the patch is great. I'm tweaking it a little to reduce test 
footprint. wip.

> EmbeddedSolrServer does not support SchemaAPI
> -
>
> Key: SOLR-10134
> URL: https://issues.apache.org/jira/browse/SOLR-10134
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server, SolrJ
>Affects Versions: 6.4.1
>Reporter: Robert Alexandersson
>  Labels: test-driven
> Attachments: SOLR-10134.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The EmbeddedSolrServer server does not support calls to the POST methods of 
> SchemaAPI using SolRJ api. The reason is that the httpMethod param is never 
> set by the EmbeddedSolrServer#request(SolrRequest, String) and this is later 
> required by the SchemaHandler class that actually performs the call at 
> SchemaHandler#handleRequestBody(SolrQueryRequest, SolrQueryResponse). 
> Proposal is to enhance the EmbeddedSolrServer to forward the httpMethod at 
> aprox row 174 with the following: "req.getContext().put("httpMethod", 
> request.getMethod().name());". This change requires the Factory methods of 
> SolrJ to add the intended method to be used example : new 
> SchemaRequest.AddField() should append the POST method similar to how the 
> SchemaRequest.Field appends the GET method.
> I have written a separate EmbeddedSolrServer that replaces the one in SolR. 
> It works for now and fields can be created on the fly using the SchemaAPI of 
> the solrj client, but would like to be able to remove this workaround.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 10894 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J0 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [24/694 (1!)] on J0 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 64755 lines...]



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

[jira] [Updated] (SOLR-9994) Add support for CollapseQParser with PointFields

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-9994:

Attachment: SOLR-9994.patch

- Patch which adds Points support to the collapse query parser
- In the tests we change the fields from "test_ti"/"test_tl"/"test_tf" to 
"test_i"/"test_l"/"test_f" dynamic fields.
- These dynamic fields are randomly picked between the Trie and Point field 
variants by SolrTestCaseJ4.

> Add support for CollapseQParser with PointFields
> 
>
> Key: SOLR-9994
> URL: https://issues.apache.org/jira/browse/SOLR-9994
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9994.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19011/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  
org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings

Error Message:
finalOffset expected:<24> but was:<23>

Stack Trace:
java.lang.AssertionError: finalOffset expected:<24> but was:<23>
at 
__randomizedtesting.SeedInfo.seed([821B9B2715E2264F:E84024364CAC06BC]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:293)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:308)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:312)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:843)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:642)
at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:540)
at 
org.apache.lucene.analysis.core.TestRandomChains.testRandomChainsWithLargeStrings(TestRandomChains.java:880)
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.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 
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.search.TestAnalyticsQParserPlugin.initializationError

Error Message:
No runnable methods

Stack Trace:
java.lang.Exception: No runnable methods
at 
org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:166)
at 
org.junit.runners.BlockJUnit4ClassRunner.collectInitializationErrors(BlockJUnit4ClassRunner.java:102)
at org.junit.runners.ParentRunner.validate(ParentRunner.java:344)
at org.junit.runners.ParentRunner.(ParentRunner.java:74)
at 
org.junit.runners.BlockJUnit4ClassRunner.(BlockJUnit4ClassRunner.java:55)
at 
org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at 
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at 
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:239)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)




Build Log:
[...truncated 12898 lines...]
   [junit4] Suite: org.apache.solr.search.TestAnalyticsQParserPlugin
   [junit4] ERROR   0.00s J1 | TestAnalyticsQParserPlugin.initializationError 
<<<
   [junit4]> Throwable #1: java.lang.Exception: No runnable methods
   [junit4] Completed [626/696 (1!)] on J1 in 0.00s, 1 test, 1 error <<< 
FAILURES!

[...truncated 62908 lines...]


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

[jira] [Commented] (SOLR-5944) Support updates of numeric DocValues

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-5944:
-

Hi Ishan,

While working on integrating points in the collapse query parser on SOLR-9994 , 
I was looking at how the existing tests were randomizing points /trie fields.

Most tests use the "solr.tests.intClass" system property including how it's 
randomized in SolrTestCaseJ4

 In this feature we use the "solr.tests.intClassName" system property. Although 
it means the same thing a small improvement here will be to use the same 
property names to make our tests more consistent?

I think we just need to rename these fields in {{schema-inplace-updates.xml}} 
and it's usages?

{code}
  
  
  
  
{code}

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 6.5, master (7.0)
>
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, master-vs-5944-regular-updates.png, 
> regular-vs-dv-updates.png, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[JIRA]

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

Jan Høydahl edited comment on SOLR-10147 at 2/20/17 7:27 PM:
-

I'm not sure it is even important to distinguish between various states of an 
inactive shard/replica? We could use _italics_ or *bold*, or even 
-strikethrough- in order to not being dependent on colors. BTW, it is bad 
practice to rely on colors only, ref color blind people or if you print the 
page on a B/W printer :-)

So to try to improve on the existing states as well, what if we create a scheme 
with combinations of color and style, here is an attempt where we use bold to 
signify Leader, italic to mean recovering and strike-through means inactive, 
while double strikethrough means Gone. See screen shot:
!color_and_style.png!

http://jsfiddle.net/janhoy/w4Ldbhy7/4/


was (Author: janhoy):
I'm not sure it is even important to distinguish between various states of an 
inactive shard/replica? We could use _italics_ or *bold*, or even 
-strikethrough- in order to not being dependent on colors. BTW, it is bad 
practice to rely on colors only, ref color blind people or if you print the 
page on a B/W printer :-)

So to try to improve on the existing colors as well, what if we create a scheme 
with combinations of color and style, here is an attempt where we use bold to 
signify Leader, italic to mean recovering, strike-through means down or 
inactive, while double strikethrough means Gone. See screen shot:
!color_and_style.png!

http://jsfiddle.net/janhoy/w4Ldbhy7/3/

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: color_and_style.png, screenshot-1.png, SOLR-10147.patch, 
> SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[JIRA]

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

Jan Høydahl updated SOLR-10147:
---
Attachment: color_and_style.png

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: color_and_style.png, screenshot-1.png, SOLR-10147.patch, 
> SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[JIRA]

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

Jan Høydahl updated SOLR-10147:
---
Attachment: (was: color_and_style.png)

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: color_and_style.png, screenshot-1.png, SOLR-10147.patch, 
> SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[JIRA]

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

Jan Høydahl updated SOLR-10147:
---
Attachment: color_and_style.png

I'm not sure it is even important to distinguish between various states of an 
inactive shard/replica? We could use _italics_ or *bold*, or even 
-strikethrough- in order to not being dependent on colors. BTW, it is bad 
practice to rely on colors only, ref color blind people or if you print the 
page on a B/W printer :-)

So to try to improve on the existing colors as well, what if we create a scheme 
with combinations of color and style, here is an attempt where we use bold to 
signify Leader, italic to mean recovering, strike-through means down or 
inactive, while double strikethrough means Gone. See screen shot:
!color_and_style.png!

http://jsfiddle.net/janhoy/w4Ldbhy7/3/

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: color_and_style.png, screenshot-1.png, SOLR-10147.patch, 
> SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 42019 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/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:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (24.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 30.6 MB in 0.03 sec (1187.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 65.0 MB in 0.07 sec (969.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 75.4 MB in 0.07 sec (1121.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6206 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6206 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.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 215 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 (271.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 40.3 MB in 0.04 sec (1064.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 147.4 MB in 0.14 sec (1082.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 156.7 MB in 0.14 sec (1105.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.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=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.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 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.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 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=2063). Happy searching!
   

[jira] [Commented] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-10053:
-

[~markrmil...@gmail.com] I suspect its a same issue (HADOOP-14044) with renew 
functionality. Can you enable debug logs (using my earlier patch) and try to 
reproduce it? Will do the same on my end...

> TestSolrCloudWithDelegationTokens failures
> --
>
> Key: SOLR-10053
> URL: https://issues.apache.org/jira/browse/SOLR-10053
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Attachments: fail.log, stdout, stdout, stdout, stdout
>
>
> The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have 
> been so far unable to reproduce them using the failing seeds. However, 
> beasting these tests seem to cause failures (once after about 10-12 runs).
> Latest Jenkins failure: 
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/
> It wasn't apparent what caused these failures. To cut down the noise on 
> Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) 
> annotation and continue to debug and fix this test.
> WDYT, [~markrmil...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-10147 at 2/20/17 6:38 PM:
--

Mr. Høydahl,

Ah, how did I miss that!. Kindly provide your suggestion on how to design this: 
probably 'grey' for replica, when shard is inactive and replica is active, and 
rest for replicas, everything as it is?

Patch uploaded for the same.


was (Author: sarkaramr...@gmail.com):
Mr. Høydahl,

Ah, how did I miss that!. Kindly provide your suggestion on how to design this: 
probably Color 'grey' for replica, when shard is inactive and replica is 
active, and rest for replicas, everything as it is?

Patch uploaded for the same.

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10176) add @Ignore to forbiddenApis/solr.txt

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-10176:
---
Attachment: SOLR-10176.patch

Proposed patch, to be committed only after existing @Ignore use in solr code 
has been replaced.

> add @Ignore to forbiddenApis/solr.txt
> -
>
> Key: SOLR-10176
> URL: https://issues.apache.org/jira/browse/SOLR-10176
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10176.patch
>
>
> Once the remaining few @Ignore uses have been replaced this would then 
> prevent the introduction of further ignored test code. What do you think?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10176) add @Ignore to forbiddenApis/solr.txt

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-10176:
--

 Summary: add @Ignore to forbiddenApis/solr.txt
 Key: SOLR-10176
 URL: https://issues.apache.org/jira/browse/SOLR-10176
 Project: Solr
  Issue Type: Wish
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


Once the remaining few @Ignore uses have been replaced this would then prevent 
the introduction of further ignored test code. What do you think?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([3139DB3C5C270BAB:B96DE4E6F2DB6653]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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-10175) replace @Ignore for TestAnalyticsQParserPlugin

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10175:


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

SOLR-10175: turn TestAnalyticsQParserPlugin's @Ignore into @AwaitsFix


> replace @Ignore for TestAnalyticsQParserPlugin
> --
>
> Key: SOLR-10175
> URL: https://issues.apache.org/jira/browse/SOLR-10175
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> As per the latest SOLR-10032 report any tests marked @Ignore are not run and 
> included in the report as mission-failed. This ticket is to first mark the 
> test as @AwaitsFix and then to either use this ticket to fix it or to remove 
> the AwaitsFix tag if there is nothing to fix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7688) add a OneMergeWrappingMergePolicy class

[ASF subversion and git services (JIRA)]

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

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

Commit 180614c1491a7e8ffa7b5aba5bab0ad646e2d5f4 in lucene-solr's branch 
refs/heads/branch_6x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=180614c ]

LUCENE-7688: Add OneMergeWrappingMergePolicy class. (Keith Laban, Christine 
Poerschke)


> add a OneMergeWrappingMergePolicy class
> ---
>
> Key: LUCENE-7688
> URL: https://issues.apache.org/jira/browse/LUCENE-7688
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7688.patch
>
>
> This ticket splits out the lucene part of the changes proposed in SOLR-10046 
> for a conversation on whether or not the {{OneMergeWrappingMergePolicy}} 
> class would best be located in Lucene or in Solr.
> (As an aside, the proposed use of 
> [java.util.function.UnaryOperator|https://docs.oracle.com/javase/8/docs/api/java/util/function/UnaryOperator.html]
>  causes {{ant documentation-lint}} to fail, I have created LUCENE-7689 
> separately for that.)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7688) add a OneMergeWrappingMergePolicy class

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7688: Add OneMergeWrappingMergePolicy class. (Keith Laban, Christine 
Poerschke)


> add a OneMergeWrappingMergePolicy class
> ---
>
> Key: LUCENE-7688
> URL: https://issues.apache.org/jira/browse/LUCENE-7688
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7688.patch
>
>
> This ticket splits out the lucene part of the changes proposed in SOLR-10046 
> for a conversation on whether or not the {{OneMergeWrappingMergePolicy}} 
> class would best be located in Lucene or in Solr.
> (As an aside, the proposed use of 
> [java.util.function.UnaryOperator|https://docs.oracle.com/javase/8/docs/api/java/util/function/UnaryOperator.html]
>  causes {{ant documentation-lint}} to fail, I have created LUCENE-7689 
> separately for that.)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10175) replace @Ignore for TestAnalyticsQParserPlugin

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10175:


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

SOLR-10175: turn TestAnalyticsQParserPlugin's @Ignore into @AwaitsFix


> replace @Ignore for TestAnalyticsQParserPlugin
> --
>
> Key: SOLR-10175
> URL: https://issues.apache.org/jira/browse/SOLR-10175
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> As per the latest SOLR-10032 report any tests marked @Ignore are not run and 
> included in the report as mission-failed. This ticket is to first mark the 
> test as @AwaitsFix and then to either use this ticket to fix it or to remove 
> the AwaitsFix tag if there is nothing to fix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[JIRA]

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

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

Attaching new patch which applies to master

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-10147 at 2/20/17 5:39 PM:
--

Mr. Høydahl,

Ah, how did I miss that!. Kindly provide your suggestion on how to design this: 
probably Color 'grey' for replica, when shard is inactive and replica is 
active, and rest for replicas, everything as it is?

Patch uploaded for the same.


was (Author: sarkaramr...@gmail.com):
Mr. Høydahl,

Ah, how did I miss that!. Kindly provide your suggestion on how to design this: 
probably Color 'grey' for replica, when shard is inactive and replica is 
active, and rest for replicas, everything as it is?

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10147:

Attachment: SOLR-10147.patch

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10175) replace @Ignore for TestAnalyticsQParserPlugin

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-10175:
--

 Summary: replace @Ignore for TestAnalyticsQParserPlugin
 Key: SOLR-10175
 URL: https://issues.apache.org/jira/browse/SOLR-10175
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


As per the latest SOLR-10032 report any tests marked @Ignore are not run and 
included in the report as mission-failed. This ticket is to first mark the test 
as @AwaitsFix and then to either use this ticket to fix it or to remove the 
AwaitsFix tag if there is nothing to fix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10147:
-

Mr. Høydahl,

Ah, how did I miss that!. Kindly provide your suggestion on how to design this: 
probably Color 'grey' for replica, when shard is inactive and replica is 
active, and rest for replicas, everything as it is?

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10174) fix 3x in @Ignore TestLTRReRankingPipeline and TestMultipleAdditiveTreesModel

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-10174:
--

 Summary: fix 3x in @Ignore TestLTRReRankingPipeline and 
TestMultipleAdditiveTreesModel
 Key: SOLR-10174
 URL: https://issues.apache.org/jira/browse/SOLR-10174
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Christine Poerschke
Priority: Minor


https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/src/test/org/apache/solr/ltr/TestLTRReRankingPipeline.java#L105

https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/src/test/org/apache/solr/ltr/TestLTRReRankingPipeline.java#L162

https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/src/test/org/apache/solr/ltr/model/TestMultipleAdditiveTreesModel.java#L82



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[JIRA]

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

Jan Høydahl commented on SOLR-10147:


i like it, but will let [~upayavira] and others who can speak for consistency 
in colors etc have a say. 
In your patch you set replica states to "Inactive" unless the node is "gone". 
Will a replica for an inactive shard never be "Recovering" or "Down"?

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10172) Sorl 6 with jetty issues

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-10172:

Fix Version/s: 6.4.2

> Sorl 6 with jetty issues
> 
>
> Key: SOLR-10172
> URL: https://issues.apache.org/jira/browse/SOLR-10172
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Abc 
>Priority: Blocker
> Fix For: 6.4.2
>
>
> Issues with solr settings while migrating from solr 4.0 to solr6.0.
> Issue Faced : My cpu consumption goes to unacceptable levels. ie. load on 
> solr4.0 is between 6 to 10 while load on solr 6 reaches 100 and since its the 
> production i rolled back quickly.
> My Solr4 setting
>  - Running on tomcat
>  - JVM Memory : 16GB
>  - 24 core cpu
>  - JVM settings :
>- JVM Runtime Java HotSpot(TM) 64-Bit Server VM (24.45-b08) 
>- Processors   24 
>- Args : Paths mentioned here
> **My Solr6 setting**
>  - Running on jetty
>  - JVM Memory : 20GB
>  - 32 core cpu
>  - JVM settings :
>- Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 1.8.0_45 25.45-b02
>- Processors   32
>- Args
>   - DSTOP.KEY=solrrocks
>   - DSTOP.PORT=7983
>   - Djetty.home=/usr/local/solr-6.4.1/server-Djetty.port=8983
>   - 
> Dlog4j.configuration=file:/usr/local/solr-6.4.1/example/resources/log4j.properties
>   - 
> Dsolr.install.dir=/usr/local/solr-6.4.1-Dsolr.log.dir=/usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - Dsolr.log.muteconsole
>   - 
> Dsolr.solr.home=/usr/local/solr-6.4.1/example/techproducts/solr-Duser.timezone=US/Eastern
>   - XX:+AggressiveOpts
>   - XX:+CMSParallelRemarkEnabled
>   - XX:+CMSScavengeBeforeRemark
>   - XX:+ParallelRefProcEnabled
>   - XX:+PrintGCApplicationStoppedTime
>   - XX:+PrintGCDateStamps
>   - XX:+PrintGCDetails
>   - XX:+PrintGCTimeStamps
>   - XX:+PrintHeapAtGC
>   - XX:+PrintTenuringDistribution
>   - XX:+UseCMSInitiatingOccupancyOnly
>   - XX:+UseConcMarkSweepGC
>   - XX:+UseGCLogFileRotation
>   - XX:-UseSuperWord
>   - XX:CMSFullGCsBeforeCompaction=1
>   - XX:CMSInitiatingOccupancyFraction=70
>   - XX:CMSMaxAbortablePrecleanTime=6000
>   - XX:CMSTriggerPermRatio=80
>   - XX:GCLogFileSize=20M
>   - XX:MaxTenuringThreshold=8
>   - XX:NewRatio=2
>   - XX:NumberOfGCLogFiles=9
>   - XX:OnOutOfMemoryError=/usr/local/solr-6.4.1/bin/oom_solr.sh 8983 
> /usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - XX:PretenureSizeThreshold=64m
>   - XX:SurvivorRatio=15
>   - 
> XX:TargetSurvivorRatio=90-Xloggc:/usr/local/solr-6.4.1/example/techproducts/solr/../logs/solr_gc.log-Xms21g-Xmx21g-Xss256k-verbose:gc
> Bug :
> In this version, there must be issue regarding cpu utilization.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10172) Sorl 6 with jetty issues

[Shawn Heisey (JIRA)]

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

Shawn Heisey resolved SOLR-10172.
-
Resolution: Duplicate

Resolving as duplicate.  We expect a 6.4.2 release very soon to address this 
issue.

> Sorl 6 with jetty issues
> 
>
> Key: SOLR-10172
> URL: https://issues.apache.org/jira/browse/SOLR-10172
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Abc 
>Priority: Blocker
>
> Issues with solr settings while migrating from solr 4.0 to solr6.0.
> Issue Faced : My cpu consumption goes to unacceptable levels. ie. load on 
> solr4.0 is between 6 to 10 while load on solr 6 reaches 100 and since its the 
> production i rolled back quickly.
> My Solr4 setting
>  - Running on tomcat
>  - JVM Memory : 16GB
>  - 24 core cpu
>  - JVM settings :
>- JVM Runtime Java HotSpot(TM) 64-Bit Server VM (24.45-b08) 
>- Processors   24 
>- Args : Paths mentioned here
> **My Solr6 setting**
>  - Running on jetty
>  - JVM Memory : 20GB
>  - 32 core cpu
>  - JVM settings :
>- Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 1.8.0_45 25.45-b02
>- Processors   32
>- Args
>   - DSTOP.KEY=solrrocks
>   - DSTOP.PORT=7983
>   - Djetty.home=/usr/local/solr-6.4.1/server-Djetty.port=8983
>   - 
> Dlog4j.configuration=file:/usr/local/solr-6.4.1/example/resources/log4j.properties
>   - 
> Dsolr.install.dir=/usr/local/solr-6.4.1-Dsolr.log.dir=/usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - Dsolr.log.muteconsole
>   - 
> Dsolr.solr.home=/usr/local/solr-6.4.1/example/techproducts/solr-Duser.timezone=US/Eastern
>   - XX:+AggressiveOpts
>   - XX:+CMSParallelRemarkEnabled
>   - XX:+CMSScavengeBeforeRemark
>   - XX:+ParallelRefProcEnabled
>   - XX:+PrintGCApplicationStoppedTime
>   - XX:+PrintGCDateStamps
>   - XX:+PrintGCDetails
>   - XX:+PrintGCTimeStamps
>   - XX:+PrintHeapAtGC
>   - XX:+PrintTenuringDistribution
>   - XX:+UseCMSInitiatingOccupancyOnly
>   - XX:+UseConcMarkSweepGC
>   - XX:+UseGCLogFileRotation
>   - XX:-UseSuperWord
>   - XX:CMSFullGCsBeforeCompaction=1
>   - XX:CMSInitiatingOccupancyFraction=70
>   - XX:CMSMaxAbortablePrecleanTime=6000
>   - XX:CMSTriggerPermRatio=80
>   - XX:GCLogFileSize=20M
>   - XX:MaxTenuringThreshold=8
>   - XX:NewRatio=2
>   - XX:NumberOfGCLogFiles=9
>   - XX:OnOutOfMemoryError=/usr/local/solr-6.4.1/bin/oom_solr.sh 8983 
> /usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - XX:PretenureSizeThreshold=64m
>   - XX:SurvivorRatio=15
>   - 
> XX:TargetSurvivorRatio=90-Xloggc:/usr/local/solr-6.4.1/example/techproducts/solr/../logs/solr_gc.log-Xms21g-Xmx21g-Xss256k-verbose:gc
> Bug :
> In this version, there must be issue regarding cpu utilization.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10172) Sorl 6 with jetty issues

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-10172:
-

It does indeed look like a duplicate of SOLR-10130.  This is a problem that 
only affects 6.4.0 and 6.4.1.

Your problem statement says version 6.0 ... but then in the details, the 
directory path contains "6.4.1" ... these are *VERY* different versions.  There 
are six releases and ten months between these versions.


> Sorl 6 with jetty issues
> 
>
> Key: SOLR-10172
> URL: https://issues.apache.org/jira/browse/SOLR-10172
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Abc 
>Priority: Blocker
>
> Issues with solr settings while migrating from solr 4.0 to solr6.0.
> Issue Faced : My cpu consumption goes to unacceptable levels. ie. load on 
> solr4.0 is between 6 to 10 while load on solr 6 reaches 100 and since its the 
> production i rolled back quickly.
> My Solr4 setting
>  - Running on tomcat
>  - JVM Memory : 16GB
>  - 24 core cpu
>  - JVM settings :
>- JVM Runtime Java HotSpot(TM) 64-Bit Server VM (24.45-b08) 
>- Processors   24 
>- Args : Paths mentioned here
> **My Solr6 setting**
>  - Running on jetty
>  - JVM Memory : 20GB
>  - 32 core cpu
>  - JVM settings :
>- Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 1.8.0_45 25.45-b02
>- Processors   32
>- Args
>   - DSTOP.KEY=solrrocks
>   - DSTOP.PORT=7983
>   - Djetty.home=/usr/local/solr-6.4.1/server-Djetty.port=8983
>   - 
> Dlog4j.configuration=file:/usr/local/solr-6.4.1/example/resources/log4j.properties
>   - 
> Dsolr.install.dir=/usr/local/solr-6.4.1-Dsolr.log.dir=/usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - Dsolr.log.muteconsole
>   - 
> Dsolr.solr.home=/usr/local/solr-6.4.1/example/techproducts/solr-Duser.timezone=US/Eastern
>   - XX:+AggressiveOpts
>   - XX:+CMSParallelRemarkEnabled
>   - XX:+CMSScavengeBeforeRemark
>   - XX:+ParallelRefProcEnabled
>   - XX:+PrintGCApplicationStoppedTime
>   - XX:+PrintGCDateStamps
>   - XX:+PrintGCDetails
>   - XX:+PrintGCTimeStamps
>   - XX:+PrintHeapAtGC
>   - XX:+PrintTenuringDistribution
>   - XX:+UseCMSInitiatingOccupancyOnly
>   - XX:+UseConcMarkSweepGC
>   - XX:+UseGCLogFileRotation
>   - XX:-UseSuperWord
>   - XX:CMSFullGCsBeforeCompaction=1
>   - XX:CMSInitiatingOccupancyFraction=70
>   - XX:CMSMaxAbortablePrecleanTime=6000
>   - XX:CMSTriggerPermRatio=80
>   - XX:GCLogFileSize=20M
>   - XX:MaxTenuringThreshold=8
>   - XX:NewRatio=2
>   - XX:NumberOfGCLogFiles=9
>   - XX:OnOutOfMemoryError=/usr/local/solr-6.4.1/bin/oom_solr.sh 8983 
> /usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - XX:PretenureSizeThreshold=64m
>   - XX:SurvivorRatio=15
>   - 
> XX:TargetSurvivorRatio=90-Xloggc:/usr/local/solr-6.4.1/example/techproducts/solr/../logs/solr_gc.log-Xms21g-Xmx21g-Xss256k-verbose:gc
> Bug :
> In this version, there must be issue regarding cpu utilization.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-10147 at 2/20/17 4:51 PM:
--

Mr. Høydahl

SOLR-10147.patch is first draft for what we are trying to achieve here. I made 
changes in existing CSS as _'grey'_ color is very fine and both _'Inactive'_ 
and _'Gone'_ were almost identical. Made 'Gone' more lighter.

modified:   webapp/web/css/angular/cloud.css
modified:   webapp/web/js/angular/controllers/cloud.js
modified:   webapp/web/partials/cloud.html

Screenshot is attached, color combination is to be decided, whether this is 
good enough or we need to tweak the hex color code more.


was (Author: sarkaramr...@gmail.com):
Mr. Høydahl

SOLR-10147.patch is first draft for what we are trying to achieve here. I made 
changes in existing CSS as _'grey'_ color is very fine and both _'Inactive'_ 
and _'Gone'_ were almost identical. Made 'Gone' more lighter.

Screenshot is attached, color combination is to be decided, whether this is 
good enough or we need to tweak the hex color code more.

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-10147 at 2/20/17 4:48 PM:
--

Mr. Høydahl

SOLR-10147.patch is first draft for what we are trying to achieve here. I made 
changes in existing CSS as _'grey'_ color is very fine and both _'Inactive'_ 
and _'Gone'_ were almost identical. Made 'Gone' more lighter.

Screenshot is attached, color combination is to be decided, whether this is 
good enough or we need to tweak the hex color code more.


was (Author: sarkaramr...@gmail.com):
Mr. Høydahl

SOLR-10147.patch is first draft for what we are trying to achieve here. I made 
changes in existing CSS as 'grey' color is very fine and both 'Inactive' and 
'Gone' were almost identical. Made 'Gone' more lighter.

Screenshot is attached, color combination is to be decided, whether this is 
good enough or we need to tweak the hex color code more.

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([FE6781C7762E9AB9:7633BE1DD8D2F741]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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] [Updated] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10147:

Attachment: screenshot-1.png

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10147:
-

Mr. Høydahl

SOLR-10147.patch is first draft for what we are trying to achieve here. I made 
changes in existing CSS as 'grey' color is very fine and both 'Inactive' and 
'Gone' were almost identical. Made 'Gone' more lighter.

Screenshot is attached, color combination is to be decided, whether this is 
good enough or we need to tweak the hex color code more.

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: screenshot-1.png, SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10147) Admin UI -> Cloud -> Graph: Impossible to see shard state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10147:

Attachment: SOLR-10147.patch

> Admin UI -> Cloud -> Graph: Impossible to see shard state
> -
>
> Key: SOLR-10147
> URL: https://issues.apache.org/jira/browse/SOLR-10147
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Attachments: SOLR-10147.patch
>
>
> Currently in the Cloud -> Graph view there is a legend with color codes, but 
> that is for replicas only.
> We need a way to quickly see the state of the shard, in particular if it is 
> active or inactive. For testing, create a collection, then call SPLITSHARD on 
> shard1, and you'll end up with shards {{shard1}}, {{shard1_0}} and 
> {{shard1_1}}. It is not possible to see which one is active or inactive.
> Also, the replicas belonging to the inactive shard are still marked with 
> green "Active", while in reality they are "Inactive".
> The simplest would be to add a new state "Inactive" with color e.g. blue, 
> which would be used on both shard and replica level. But since an inactive 
> replica could also be "Gone" or "Down", there should be some way to indicate 
> both at the same time...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10142) replace @Ignore/@AwaitsFix for TestClassNameShortening

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-10142:


@Ignore is JUnit's annotation and it cannot be "enabled" (it could, 
theoretically, but I don't think it'd be of much value). @BadApple, @Slow and 
the like are test-groups (annotations that are themselves annotated with a 
meta-annotation @TestGroup). 

bq. -Dtests.awaitsfix=true 

You can also use the filtering expression (which is a Boolean expression and 
can be complex):

{code}
-Dtests.filter="@slow and @badapple"
{code}

As always, the test help is under {{ant test-help}}.

> replace @Ignore/@AwaitsFix for TestClassNameShortening
> --
>
> Key: SOLR-10142
> URL: https://issues.apache.org/jira/browse/SOLR-10142
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10142.patch
>
>
> As per the latest SOLR-10032 report any tests marked {{@Ignore}} are not run 
> and included in the report as _mission-failed_. This ticket is to first mark 
> the test as {{@AwaitsFix}} and then to either use this ticket to fix it or to 
> remove the AwaitsFix tag if there is nothing to fix.
> Via locals runs of
> {code}
> ant beast -Dbeast.iters=10 -Dtest.dups=2 -Dtestcase=TestClassNameShortening
> {code}
> i couldn't make the test fail so far.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10142) replace @Ignore/@AwaitsFix for TestClassNameShortening

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10142:


bq. Found an answer e.g. -Dtests.awaitsfix=true can be used.

Sorry, missed that comment. Right, and you can use -Dtests.badapple=true to run 
@BadApple tests. I don't think there is a way to run @Ignore tests.

> replace @Ignore/@AwaitsFix for TestClassNameShortening
> --
>
> Key: SOLR-10142
> URL: https://issues.apache.org/jira/browse/SOLR-10142
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10142.patch
>
>
> As per the latest SOLR-10032 report any tests marked {{@Ignore}} are not run 
> and included in the report as _mission-failed_. This ticket is to first mark 
> the test as {{@AwaitsFix}} and then to either use this ticket to fix it or to 
> remove the AwaitsFix tag if there is nothing to fix.
> Via locals runs of
> {code}
> ant beast -Dbeast.iters=10 -Dtest.dups=2 -Dtestcase=TestClassNameShortening
> {code}
> i couldn't make the test fail so far.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10173) Enable extension/customization of HttpShardHandler by increasing visibility

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-10173:
--

Assignee: Christine Poerschke

> Enable extension/customization of HttpShardHandler by increasing visibility
> ---
>
> Key: SOLR-10173
> URL: https://issues.apache.org/jira/browse/SOLR-10173
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ramsey Haddad
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: solr-10173.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Increase visibility of 2 elements of HttpShardHandlerFactory from "private" 
> to "protected" to facilitate extension of the class. Make 
> ReplicaListTransformer "public" to enable implementation of the interface in 
> custom classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10173) Enable extension/customization of HttpShardHandler by increasing visibility

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10173:


This will allow derived classes such as
{code}
package com.mycompany.myteam.solr.handler.component;

public class HttpShardHandlerFactory extends 
org.apache.solr.handler.component.HttpShardHandlerFactory {
  @Override
  protected ReplicaListTransformer getReplicaListTransformer(final 
SolrQueryRequest req) {
if (...) {
  ... custom logic possibly using r(andomisation) ...
} else {
  return super.getReplicaListTransformer(req);
}
  }
}
{code}

Looks good to me.

> Enable extension/customization of HttpShardHandler by increasing visibility
> ---
>
> Key: SOLR-10173
> URL: https://issues.apache.org/jira/browse/SOLR-10173
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ramsey Haddad
>Priority: Minor
> Attachments: solr-10173.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Increase visibility of 2 elements of HttpShardHandlerFactory from "private" 
> to "protected" to facilitate extension of the class. Make 
> ReplicaListTransformer "public" to enable implementation of the interface in 
> custom classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10173) Enable extension/customization of HttpShardHandler by increasing visibility

[Ramsey Haddad (JIRA)]

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

Ramsey Haddad updated SOLR-10173:
-
Summary: Enable extension/customization of HttpShardHandler by increasing 
visibility  (was: Enable extension/customization of HttpShardHandler by 
increasing visability)

> Enable extension/customization of HttpShardHandler by increasing visibility
> ---
>
> Key: SOLR-10173
> URL: https://issues.apache.org/jira/browse/SOLR-10173
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ramsey Haddad
>Priority: Minor
> Attachments: solr-10173.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Increase visibility of 2 elements of HttpShardHandlerFactory from "private" 
> to "protected" to facilitate extension of the class. Make 
> ReplicaListTransformer "public" to enable implementation of the interface in 
> custom classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10173) Enable extension/customization of HttpShardHandler by increasing visability

[Ramsey Haddad (JIRA)]

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

Ramsey Haddad updated SOLR-10173:
-
Attachment: solr-10173.patch

> Enable extension/customization of HttpShardHandler by increasing visability
> ---
>
> Key: SOLR-10173
> URL: https://issues.apache.org/jira/browse/SOLR-10173
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ramsey Haddad
>Priority: Minor
> Attachments: solr-10173.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Increase visibility of 2 elements of HttpShardHandlerFactory from "private" 
> to "protected" to facilitate extension of the class. Make 
> ReplicaListTransformer "public" to enable implementation of the interface in 
> custom classes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10173) Enable extension/customization of HttpShardHandler by increasing visability

[Ramsey Haddad (JIRA)]

Ramsey Haddad created SOLR-10173:


 Summary: Enable extension/customization of HttpShardHandler by 
increasing visability
 Key: SOLR-10173
 URL: https://issues.apache.org/jira/browse/SOLR-10173
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ramsey Haddad
Priority: Minor


Increase visibility of 2 elements of HttpShardHandlerFactory from "private" to 
"protected" to facilitate extension of the class. Make ReplicaListTransformer 
"public" to enable implementation of the interface in custom classes.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([FF84E2CE3280FD68:77D0DD149C7C9090]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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-10172) Sorl 6 with jetty issues

[Ere Maijala (JIRA)]

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

Ere Maijala commented on SOLR-10172:


Duplicate of SOLR-10130?

> Sorl 6 with jetty issues
> 
>
> Key: SOLR-10172
> URL: https://issues.apache.org/jira/browse/SOLR-10172
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Abc 
>Priority: Blocker
>
> Issues with solr settings while migrating from solr 4.0 to solr6.0.
> Issue Faced : My cpu consumption goes to unacceptable levels. ie. load on 
> solr4.0 is between 6 to 10 while load on solr 6 reaches 100 and since its the 
> production i rolled back quickly.
> My Solr4 setting
>  - Running on tomcat
>  - JVM Memory : 16GB
>  - 24 core cpu
>  - JVM settings :
>- JVM Runtime Java HotSpot(TM) 64-Bit Server VM (24.45-b08) 
>- Processors   24 
>- Args : Paths mentioned here
> **My Solr6 setting**
>  - Running on jetty
>  - JVM Memory : 20GB
>  - 32 core cpu
>  - JVM settings :
>- Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 1.8.0_45 25.45-b02
>- Processors   32
>- Args
>   - DSTOP.KEY=solrrocks
>   - DSTOP.PORT=7983
>   - Djetty.home=/usr/local/solr-6.4.1/server-Djetty.port=8983
>   - 
> Dlog4j.configuration=file:/usr/local/solr-6.4.1/example/resources/log4j.properties
>   - 
> Dsolr.install.dir=/usr/local/solr-6.4.1-Dsolr.log.dir=/usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - Dsolr.log.muteconsole
>   - 
> Dsolr.solr.home=/usr/local/solr-6.4.1/example/techproducts/solr-Duser.timezone=US/Eastern
>   - XX:+AggressiveOpts
>   - XX:+CMSParallelRemarkEnabled
>   - XX:+CMSScavengeBeforeRemark
>   - XX:+ParallelRefProcEnabled
>   - XX:+PrintGCApplicationStoppedTime
>   - XX:+PrintGCDateStamps
>   - XX:+PrintGCDetails
>   - XX:+PrintGCTimeStamps
>   - XX:+PrintHeapAtGC
>   - XX:+PrintTenuringDistribution
>   - XX:+UseCMSInitiatingOccupancyOnly
>   - XX:+UseConcMarkSweepGC
>   - XX:+UseGCLogFileRotation
>   - XX:-UseSuperWord
>   - XX:CMSFullGCsBeforeCompaction=1
>   - XX:CMSInitiatingOccupancyFraction=70
>   - XX:CMSMaxAbortablePrecleanTime=6000
>   - XX:CMSTriggerPermRatio=80
>   - XX:GCLogFileSize=20M
>   - XX:MaxTenuringThreshold=8
>   - XX:NewRatio=2
>   - XX:NumberOfGCLogFiles=9
>   - XX:OnOutOfMemoryError=/usr/local/solr-6.4.1/bin/oom_solr.sh 8983 
> /usr/local/solr-6.4.1/example/techproducts/solr/../logs
>   - XX:PretenureSizeThreshold=64m
>   - XX:SurvivorRatio=15
>   - 
> XX:TargetSurvivorRatio=90-Xloggc:/usr/local/solr-6.4.1/example/techproducts/solr/../logs/solr_gc.log-Xms21g-Xmx21g-Xss256k-verbose:gc
> Bug :
> In this version, there must be issue regarding cpu utilization.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10172) Sorl 6 with jetty issues

[Abc (JIRA)]

Abc  created SOLR-10172:
---

 Summary: Sorl 6 with jetty issues
 Key: SOLR-10172
 URL: https://issues.apache.org/jira/browse/SOLR-10172
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Abc 
Priority: Blocker


Issues with solr settings while migrating from solr 4.0 to solr6.0.

Issue Faced : My cpu consumption goes to unacceptable levels. ie. load on 
solr4.0 is between 6 to 10 while load on solr 6 reaches 100 and since its the 
production i rolled back quickly.

My Solr4 setting

 - Running on tomcat
 - JVM Memory : 16GB
 - 24 core cpu
 - JVM settings :
   - JVM Runtime Java HotSpot(TM) 64-Bit Server VM (24.45-b08) 
   - Processors   24 
   - Args : Paths mentioned here


**My Solr6 setting**

 - Running on jetty
 - JVM Memory : 20GB
 - 32 core cpu
 - JVM settings :
   - Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 1.8.0_45 25.45-b02
   - Processors   32
   - Args
  - DSTOP.KEY=solrrocks
  - DSTOP.PORT=7983
  - Djetty.home=/usr/local/solr-6.4.1/server-Djetty.port=8983
  - 
Dlog4j.configuration=file:/usr/local/solr-6.4.1/example/resources/log4j.properties
  - 
Dsolr.install.dir=/usr/local/solr-6.4.1-Dsolr.log.dir=/usr/local/solr-6.4.1/example/techproducts/solr/../logs
  - Dsolr.log.muteconsole
  - 
Dsolr.solr.home=/usr/local/solr-6.4.1/example/techproducts/solr-Duser.timezone=US/Eastern
  - XX:+AggressiveOpts
  - XX:+CMSParallelRemarkEnabled
  - XX:+CMSScavengeBeforeRemark
  - XX:+ParallelRefProcEnabled
  - XX:+PrintGCApplicationStoppedTime
  - XX:+PrintGCDateStamps
  - XX:+PrintGCDetails
  - XX:+PrintGCTimeStamps
  - XX:+PrintHeapAtGC
  - XX:+PrintTenuringDistribution
  - XX:+UseCMSInitiatingOccupancyOnly
  - XX:+UseConcMarkSweepGC
  - XX:+UseGCLogFileRotation
  - XX:-UseSuperWord
  - XX:CMSFullGCsBeforeCompaction=1
  - XX:CMSInitiatingOccupancyFraction=70
  - XX:CMSMaxAbortablePrecleanTime=6000
  - XX:CMSTriggerPermRatio=80
  - XX:GCLogFileSize=20M
  - XX:MaxTenuringThreshold=8
  - XX:NewRatio=2
  - XX:NumberOfGCLogFiles=9
  - XX:OnOutOfMemoryError=/usr/local/solr-6.4.1/bin/oom_solr.sh 8983 
/usr/local/solr-6.4.1/example/techproducts/solr/../logs
  - XX:PretenureSizeThreshold=64m
  - XX:SurvivorRatio=15
  - 
XX:TargetSurvivorRatio=90-Xloggc:/usr/local/solr-6.4.1/example/techproducts/solr/../logs/solr_gc.log-Xms21g-Xmx21g-Xss256k-verbose:gc

Bug :
In this version, there must be issue regarding cpu utilization.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (LUCENE-7689) java.util.function.UnaryOperator related 'ant documentation-lint' failure

[Christine Poerschke (JIRA)]

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

Christine Poerschke closed LUCENE-7689.
---
Resolution: Not A Problem

The javadocs for the constructor were actually missing.

> java.util.function.UnaryOperator related 'ant documentation-lint' failure
> -
>
> Key: LUCENE-7689
> URL: https://issues.apache.org/jira/browse/LUCENE-7689
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
>
> LUCENE-7688 or SOLR-10046 propose to use Java 8's 
> [java.util.function.UnaryOperator|https://docs.oracle.com/javase/8/docs/api/java/util/function/UnaryOperator.html]
>  but that causes {{ant documentation-lint}} to fail as follows:
> {code}
> documentation:
> -documentation-lint:
>  [echo] checking for broken html...
> [jtidy] Checking for broken html (such as invalid tags)...
>[delete] Deleting directory 
> /Users/cpoerschke/all_git/lucene/build/jtidy_tmp
>  [echo] Checking for broken links...
>  [exec] 
>  [exec] Crawl/parse...
>  [exec] 
>  [exec] Verify...
>  [echo] Checking for missing docs...
>  [exec] 
>  [exec] 
> build/docs/core/org/apache/lucene/index/OneMergeWrappingMergePolicy.html
>  [exec]   missing Constructors: 
> OneMergeWrappingMergePolicy-org.apache.lucene.index.MergePolicy-java.util.function.UnaryOperator-
>  [exec] 
>  [exec] Missing javadocs were found!
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Apache Jenkins Server]

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

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

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"http://127.0.0.1:34477/solr;,   
"node_name":"127.0.0.1:34477_solr",   "state":"down"}, 
"core_node2":{   "core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"http://127.0.0.1:37372/solr;,   
"node_name":"127.0.0.1:37372_solr",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"http://127.0.0.1:34477/solr;,
  "node_name":"127.0.0.1:34477_solr",
  "state":"down"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"http://127.0.0.1:37372/solr;,
  "node_name":"127.0.0.1:37372_solr",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([543E6FBAA6D895E1:46BF7B9FFF923FC]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
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 
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 

[jira] [Commented] (SOLR-10159) DBQ, where query is based on updated value, reordered with the update doesn't work

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-10159:
--

Nice catch!

> DBQ, where query is based on updated value, reordered with the update doesn't 
> work
> --
>
> Key: SOLR-10159
> URL: https://issues.apache.org/jira/browse/SOLR-10159
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10159.patch, SOLR-10159.patch
>
>
> h2. Background/History
> If a recently updated (in-place) value is used for DBQ, the DBQ doesn't work 
> at Lucene level, unless there's an explicit commit between the update and the 
> DBQ, due to LUCENE-7344. To work around this, Yonik suggested that we use 
> ulog.openRealtimeSearcher() just before the DBQ is performed. This worked 
> fine.
> Example:
> {code}
> ADD: [id=0, dv=200, title="mytitle", _version_=100]
> UPD: [id=0, dv=300, _version_=200]
> DBQ: q="dv:300", _version_=300
> {code}
> h2. Problem discovered now
> Suppose, in the above example, the last two commands are reordered at the 
> replica. What would happen is: \(i\) the full document (\_version\_ 100) is 
> received and indexed, (ii) the DBQ is received (out of ordered) and applied, 
> and no document is deleted \[so far so good\] and this DBQ is buffered in 
> ulog.deleteByQueries map, (iii) the in-place update arrives (_version 200), 
> it is applied to the document that was added in step i. After that, the 
> buffered DBQ is applied (at DUH2.addAndDelete()). This buffered DBQ, based on 
> a value updated immediately before (step ii), fails to delete the document.
> h2. What happens exactly?
> The initial DBQ query is {{"dv:300"}}, but when it is applied, it is expanded 
> to {{"\+dv:\[300 TO 300\] -ConstantScore(frange(long(\_version\_)):\[300 TO 
> *\])"}}. In spite of doing a ulog.openRealtimeSearcher() just before the DBQ, 
> it doesn't work. 
> A different version of the query, i.e. {{"\+dv:\[300 TO 300\] 
> \+\_version\_:\[200 TO 200\]"}} also doesn't work. As I found out, *this 
> happened due to the presence of two clauses*! {{"\+dv:\[300 TO 300\]"}} 
> works, and so does {{"\+\_version\_:\[200 TO 200\]"}}, but both clauses don't 
> work together. Also, surprisingly, even {{"\+dv:\[300 TO 300\] \+dv:\[300 TO 
> 300\]"}} doesn't work (same clause repeated).
> h2. Investigation at Lucene level
> Upon some tedious investigation into the internals of Lucene, I discovered 
> that if I change the internal search (at BufferedUpdates) to use 
> Sort.RELEVANCE instead of Sort.INDEXORDER (which, I think is the default when 
> using weight/scorer), the DBQ is applied correctly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10142) replace @Ignore/@AwaitsFix for TestClassNameShortening

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-10142:
--

Assignee: (was: Christine Poerschke)

> replace @Ignore/@AwaitsFix for TestClassNameShortening
> --
>
> Key: SOLR-10142
> URL: https://issues.apache.org/jira/browse/SOLR-10142
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10142.patch
>
>
> As per the latest SOLR-10032 report any tests marked {{@Ignore}} are not run 
> and included in the report as _mission-failed_. This ticket is to first mark 
> the test as {{@AwaitsFix}} and then to either use this ticket to fix it or to 
> remove the AwaitsFix tag if there is nothing to fix.
> Via locals runs of
> {code}
> ant beast -Dbeast.iters=10 -Dtest.dups=2 -Dtestcase=TestClassNameShortening
> {code}
> i couldn't make the test fail so far.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10142) replace @Ignore for TestClassNameShortening

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10142:


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

SOLR-10142: turn TestClassNameShortening's @Ignore into @AwaitsFix


> replace @Ignore for TestClassNameShortening
> ---
>
> Key: SOLR-10142
> URL: https://issues.apache.org/jira/browse/SOLR-10142
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10142.patch
>
>
> As per the latest SOLR-10032 report any tests marked {{@Ignore}} are not run 
> and included in the report as _mission-failed_. This ticket is to first mark 
> the test as {{@AwaitsFix}} and then to either use this ticket to fix it or to 
> remove the AwaitsFix tag if there is nothing to fix.
> Via locals runs of
> {code}
> ant beast -Dbeast.iters=10 -Dtest.dups=2 -Dtestcase=TestClassNameShortening
> {code}
> i couldn't make the test fail so far.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10142) replace @Ignore/@AwaitsFix for TestClassNameShortening

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-10142:
---
Summary: replace @Ignore/@AwaitsFix for TestClassNameShortening  (was: 
replace @Ignore for TestClassNameShortening)

> replace @Ignore/@AwaitsFix for TestClassNameShortening
> --
>
> Key: SOLR-10142
> URL: https://issues.apache.org/jira/browse/SOLR-10142
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10142.patch
>
>
> As per the latest SOLR-10032 report any tests marked {{@Ignore}} are not run 
> and included in the report as _mission-failed_. This ticket is to first mark 
> the test as {{@AwaitsFix}} and then to either use this ticket to fix it or to 
> remove the AwaitsFix tag if there is nothing to fix.
> Via locals runs of
> {code}
> ant beast -Dbeast.iters=10 -Dtest.dups=2 -Dtestcase=TestClassNameShortening
> {code}
> i couldn't make the test fail so far.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10142) replace @Ignore for TestClassNameShortening

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10142:


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

SOLR-10142: turn TestClassNameShortening's @Ignore into @AwaitsFix


> replace @Ignore for TestClassNameShortening
> ---
>
> Key: SOLR-10142
> URL: https://issues.apache.org/jira/browse/SOLR-10142
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10142.patch
>
>
> As per the latest SOLR-10032 report any tests marked {{@Ignore}} are not run 
> and included in the report as _mission-failed_. This ticket is to first mark 
> the test as {{@AwaitsFix}} and then to either use this ticket to fix it or to 
> remove the AwaitsFix tag if there is nothing to fix.
> Via locals runs of
> {code}
> ant beast -Dbeast.iters=10 -Dtest.dups=2 -Dtestcase=TestClassNameShortening
> {code}
> i couldn't make the test fail so far.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10142) replace @Ignore for TestClassNameShortening

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10142:


bq. (Yet to figure out how ant test and ant beast can run despite the 
annotation.)

Found an answer e.g. {{-Dtests.awaitsfix=true}} can be used.


> replace @Ignore for TestClassNameShortening
> ---
>
> Key: SOLR-10142
> URL: https://issues.apache.org/jira/browse/SOLR-10142
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10142.patch
>
>
> As per the latest SOLR-10032 report any tests marked {{@Ignore}} are not run 
> and included in the report as _mission-failed_. This ticket is to first mark 
> the test as {{@AwaitsFix}} and then to either use this ticket to fix it or to 
> remove the AwaitsFix tag if there is nothing to fix.
> Via locals runs of
> {code}
> ant beast -Dbeast.iters=10 -Dtest.dups=2 -Dtestcase=TestClassNameShortening
> {code}
> i couldn't make the test fail so far.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 289 - Still unstable

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrReplicationDistributedZkTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [SolrZkClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:184)  
at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)  at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:106)  at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:226)  at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:121)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:615)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
  at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)  at 
org.apache.solr.handler.CdcrReplicatorManager.getCheckpoint(CdcrReplicatorManager.java:196)
  at 
org.apache.solr.handler.CdcrReplicatorManager.initLogReaders(CdcrReplicatorManager.java:159)
  at 
org.apache.solr.handler.CdcrReplicatorManager.stateUpdate(CdcrReplicatorManager.java:134)
  at 
org.apache.solr.handler.CdcrStateManager.callback(CdcrStateManager.java:36)  at 
org.apache.solr.handler.CdcrLeaderStateManager.setAmILeader(CdcrLeaderStateManager.java:108)
  at 
org.apache.solr.handler.CdcrLeaderStateManager.checkIfIAmLeader(CdcrLeaderStateManager.java:95)
  at 
org.apache.solr.handler.CdcrLeaderStateManager.access$400(CdcrLeaderStateManager.java:40)
  at 
org.apache.solr.handler.CdcrLeaderStateManager$LeaderStateWatcher.process(CdcrLeaderStateManager.java:150)
  at 
org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [SolrZkClient]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:184)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:106)
at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:226)
at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:615)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.handler.CdcrReplicatorManager.getCheckpoint(CdcrReplicatorManager.java:196)
at 
org.apache.solr.handler.CdcrReplicatorManager.initLogReaders(CdcrReplicatorManager.java:159)
at 
org.apache.solr.handler.CdcrReplicatorManager.stateUpdate(CdcrReplicatorManager.java:134)
at 
org.apache.solr.handler.CdcrStateManager.callback(CdcrStateManager.java:36)
at 
org.apache.solr.handler.CdcrLeaderStateManager.setAmILeader(CdcrLeaderStateManager.java:108)
at 
org.apache.solr.handler.CdcrLeaderStateManager.checkIfIAmLeader(CdcrLeaderStateManager.java:95)
at 
org.apache.solr.handler.CdcrLeaderStateManager.access$400(CdcrLeaderStateManager.java:40)
at 
org.apache.solr.handler.CdcrLeaderStateManager$LeaderStateWatcher.process(CdcrLeaderStateManager.java:150)
at 
org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 

[jira] [Comment Edited] (SOLR-10154) ant run-example fails to start due to missing solr.log.dir

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-10154 at 2/20/17 9:44 AM:
--

SOLR-10154 uploaded: added the *solr.log.dir* as property in the target name 
for {color:red}run-example{color} in build.xml. It works fine now.


was (Author: sarkaramr...@gmail.com):
Added the *solr.log.dir* as property in the target name for 
{color:red}run-example{color} in build.xml. It works fine now.

> ant run-example fails to start due to missing solr.log.dir
> --
>
> Key: SOLR-10154
> URL: https://issues.apache.org/jira/browse/SOLR-10154
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.4.1
>Reporter: Jan Høydahl
> Attachments: SOLR-10154.patch
>
>
> Running {{ant run-example}} fails to start. Problem is that this solr 
> instance is not started using bin/solr and thus does not have proper 
> variables such as {{solr.install.dir}} and {{solr.log.dir}}. Error output in 
> next comment.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/678/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.core.TestLazyCores.testNoCommit

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([DD45476DCD64221D:225E6BC064341B8]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:918)
at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:794)
at 
org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:776)
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:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound='10']
xml response was: 



  0
  0
  
*:*
  





request was:q=*:*
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:911)
... 41 more


FAILED:  

[jira] [Commented] (LUCENE-7698) CommonGramsQueryFilter in the query analyzer chain breaks phrase queries

[Ere Maijala (JIRA)]

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

Ere Maijala commented on LUCENE-7698:
-

[~mikemccand], thanks for the fix. An initial check indicates that the patch 
fixes my use case. I ran the tests in branch_6x. The patch didn't quite apply 
cleanly to branch_6_4 and after applying manually a test didn't compile:

{code}
common.compile-test:
[mkdir] Created dir: 
/Users/eremaijala/src/solr/lucene/build/analysis/common/classes/test
[javac] Compiling 279 source files to 
/Users/eremaijala/src/solr/lucene/build/analysis/common/classes/test
[javac] 
/Users/eremaijala/src/solr/lucene/analysis/common/src/test/org/apache/lucene/analysis/commongrams/TestCommonGramsQueryFilterFactory.java:103:
 error: cannot find symbol
[javac] assertGraphStrings(stream, "testing_the the_factory factory 
works");
[javac] ^
[javac]   symbol:   method assertGraphStrings(TokenStream,String)
[javac]   location: class TestCommonGramsQueryFilterFactory
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
{code}

> CommonGramsQueryFilter in the query analyzer chain breaks phrase queries
> 
>
> Key: LUCENE-7698
> URL: https://issues.apache.org/jira/browse/LUCENE-7698
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 6.4, 6.4.1
>Reporter: Ere Maijala
>  Labels: regression
> Fix For: master (7.0), 6.4.2
>
> Attachments: LUCENE-7698.patch
>
>
> (Please pardon me if the project or component are wrong!)
> CommonGramsQueryFilter breaks phrase queries. The behavior also seems to 
> change with addition or removal of adjacent terms.
> Steps to reproduce:
> 1.) Download and extract Solr (in my test case version 6.4.1) somewhere.
> 2.) Modify 
> server/solr/configsets/sample_techproducts_configs/conf/managed-schema and 
> modify text_general fieldType by adding CommonGrams(Query)Filter before 
> stopWordFilter:
>  positionIncrementGap="100">
>   
> 
>  words="stopwords.txt" />
>  words="stopwords.txt" />
> 
> 
>   
>   
> 
>  words="stopwords.txt"/>
>  words="stopwords.txt" />
>  ignoreCase="true" expand="true"/>
> 
>   
> 
> 3.) Add "with" to 
> server/solr/configsets/sample_techproducts_configs/conf/stopwords.txt and 
> make sure the file has correct line endings (extracted from Solr zip it seems 
> to contain DOS/Windows lien endings which may break things).
> 4.) Run the techproducts example with "bin/solr -e techproducts"
> 5.) Browse to 
> 
> 6.) Observe that parsedquery in the debug output is empty
> 7.) Browse to 
> 
> 8.) Observe that parsedquery contains ipod_with as expected but not 
> with_video.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [Solr Beasting Test Results] Results for 02/17/2017

[Dawid Weiss]

Umm... Looked at TestClassNameShortening just to see what can fail
there. This would have to be a test harness problem?

D.

On Mon, Feb 20, 2017 at 5:45 AM, Mark Miller  wrote:
> You can find the latest beast run tests results below, as well as a summary.
>
> I have already made a slew of improvements based on the results of this
> report, but there are many, many flakey tests to work through. If you see a
> test you are comfortable with or have some history with, please lend a hand.
> This was a more rare deep run of 100 iterations.
>
> Beast Test Results:
> https://docs.google.com/spreadsheets/d/1LEPvXbsoHtKfIcZCJZ3_P6OHp7S5g2HP2OJgU6B2sAg/edit?usp=sharing
>
> Summary:
> https://medium.com/@heismark/solr-test-report-results-notes-02-17-2017-3fd66db1adeb#.gity816cj
> --
> - Mark
> about.me/markrmiller

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