[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20694 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20694/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC 14 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionRemovesStaleZkCollectionsNode Error Message: Error from server at http://127.0.0.1:32875/solr: Could not fully remove collection: awhollynewcollection_0 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:32875/solr: Could not fully remove collection: awhollynewcollection_0 at __randomizedtesting.SeedInfo.seed([85D212656C40BEF0:77B0204421B826D]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:444) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.clearCluster(CollectionsAPIDistributedZkTest.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:968) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1481 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1481/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test Error Message: null Stack Trace: java.lang.NumberFormatException: null at __randomizedtesting.SeedInfo.seed([AE5B46876EAAA9F:82B18BB2D816C767]:0) at java.lang.Long.parseLong(Long.java:552) at java.lang.Long.parseLong(Long.java:631) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2125) at org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:209) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedt
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_144) - Build # 629 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/629/ Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testAsyncRequests Error Message: CreateCollection task did not complete! expected same: was not: Stack Trace: java.lang.AssertionError: CreateCollection task did not complete! expected same: was not: at __randomizedtesting.SeedInfo.seed([280F718ED12279FA:CC4B4D39778A3725]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotSame(Assert.java:641) at org.junit.Assert.assertSame(Assert.java:580) at org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testAsyncRequests(CollectionsAPIAsyncDistributedZkTest.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11762 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPIAsyncDistribut
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 254 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/254/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 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([7F533157BB395ECE:A0339086701E3D6B]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:884) at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:847) at org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:829) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound='10'] xml response was: 00*:* request was:q=*:* at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:877) ... 41 more FAILED: junit.framework.TestSuite.org.apache.so
[jira] [Resolved] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-11444. - Resolution: Fixed Fix Version/s: 7.2 > Improve Aliases.java and comma delimited collection list handling > - > > Key: SOLR-11444 > URL: https://issues.apache.org/jira/browse/SOLR-11444 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley > Fix For: 7.2 > > Attachments: SOLR-11444.patch, SOLR-11444.patch, > SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch > > > While starting to look at SOLR-11299 I noticed some brittleness in > assumptions about Strings that refer to a collection. Sometimes they are in > fact references to comma separated lists, which appears was added with the > introduction of collection aliases (an alias can refer to a comma delimited > list). So Java's type system kind of goes out the window when we do this. > In one case this leads to a bug -- CloudSolrClient will throw an NPE if you > try to write to such an alias. Sending an update via HTTP will allow it and > send it to the first in the list. > So this issue is about refactoring and some little improvements pertaining to > Aliases.java plus certain key spots that deal with collection references. I > don't think I want to go as far as changing the public SolrJ API except to > adding documentation on what's possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210545#comment-16210545 ] ASF subversion and git services commented on SOLR-11444: Commit da71587196eccefd8b58923dc162916c808762a9 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=da71587 ] SOLR-11444: Improve consistency of collection alias handling and collection list references. Other refactorings of nearby code too. (cherry picked from commit e001f35) > Improve Aliases.java and comma delimited collection list handling > - > > Key: SOLR-11444 > URL: https://issues.apache.org/jira/browse/SOLR-11444 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley > Attachments: SOLR-11444.patch, SOLR-11444.patch, > SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch > > > While starting to look at SOLR-11299 I noticed some brittleness in > assumptions about Strings that refer to a collection. Sometimes they are in > fact references to comma separated lists, which appears was added with the > introduction of collection aliases (an alias can refer to a comma delimited > list). So Java's type system kind of goes out the window when we do this. > In one case this leads to a bug -- CloudSolrClient will throw an NPE if you > try to write to such an alias. Sending an update via HTTP will allow it and > send it to the first in the list. > So this issue is about refactoring and some little improvements pertaining to > Aliases.java plus certain key spots that deal with collection references. I > don't think I want to go as far as changing the public SolrJ API except to > adding documentation on what's possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11444) Improve Aliases.java and comma delimited collection list handling
[ https://issues.apache.org/jira/browse/SOLR-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210544#comment-16210544 ] ASF subversion and git services commented on SOLR-11444: Commit e001f352895c83652c3cf31e3c724d29a46bb721 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e001f35 ] SOLR-11444: Improve consistency of collection alias handling and collection list references. Other refactorings of nearby code too. > Improve Aliases.java and comma delimited collection list handling > - > > Key: SOLR-11444 > URL: https://issues.apache.org/jira/browse/SOLR-11444 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley > Attachments: SOLR-11444.patch, SOLR-11444.patch, > SOLR_11444_Aliases.patch, SOLR_11444_Aliases.patch > > > While starting to look at SOLR-11299 I noticed some brittleness in > assumptions about Strings that refer to a collection. Sometimes they are in > fact references to comma separated lists, which appears was added with the > introduction of collection aliases (an alias can refer to a comma delimited > list). So Java's type system kind of goes out the window when we do this. > In one case this leads to a bug -- CloudSolrClient will throw an NPE if you > try to write to such an alias. Sending an update via HTTP will allow it and > send it to the first in the list. > So this issue is about refactoring and some little improvements pertaining to > Aliases.java plus certain key spots that deal with collection references. I > don't think I want to go as far as changing the public SolrJ API except to > adding documentation on what's possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11505) solr.cmd start of solr7.0.1 can't working in win7-64
[ https://issues.apache.org/jira/browse/SOLR-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210542#comment-16210542 ] cloverliu edited comment on SOLR-11505 at 10/19/17 3:58 AM: i use dos of win7-64 !screenshot-1.png! was (Author: cloverliu): [#comment-16209695] i use dos of win7-64 !screenshot-1.png! > solr.cmd start of solr7.0.1 can't working in win7-64 > > > Key: SOLR-11505 > URL: https://issues.apache.org/jira/browse/SOLR-11505 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCLI >Affects Versions: 7.0.1 > Environment: windows 7 >Reporter: cloverliu >Priority: Critical > Attachments: screenshot-1.png > > > http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip > solr.cmd start of this file can't working in my win7-64bit. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11505) solr.cmd start of solr7.0.1 can't working in win7-64
[ https://issues.apache.org/jira/browse/SOLR-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210542#comment-16210542 ] cloverliu commented on SOLR-11505: -- [#comment-16209695] i use dos of win7-64 !screenshot-1.png! > solr.cmd start of solr7.0.1 can't working in win7-64 > > > Key: SOLR-11505 > URL: https://issues.apache.org/jira/browse/SOLR-11505 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCLI >Affects Versions: 7.0.1 > Environment: windows 7 >Reporter: cloverliu >Priority: Critical > Attachments: screenshot-1.png > > > http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip > solr.cmd start of this file can't working in my win7-64bit. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11505) solr.cmd start of solr7.0.1 can't working in win7-64
[ https://issues.apache.org/jira/browse/SOLR-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cloverliu updated SOLR-11505: - Attachment: screenshot-1.png > solr.cmd start of solr7.0.1 can't working in win7-64 > > > Key: SOLR-11505 > URL: https://issues.apache.org/jira/browse/SOLR-11505 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCLI >Affects Versions: 7.0.1 > Environment: windows 7 >Reporter: cloverliu >Priority: Critical > Attachments: screenshot-1.png > > > http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip > solr.cmd start of this file can't working in my win7-64bit. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Release 5.5.5
Thanks Uwe. As much as I’d like to remove Morphlines, I don’t think an ancient patch version is the right place to do it. The Solr branch_5_5 Tika 1.7 support includes jmatio 1.0, which has no dependencies. Tomorrow I’ll revert SOLR-8981 and SOLR-10335 on branch_5_5, remove jmatio, then cut the RC. -- Steve www.lucidworks.com > On Oct 18, 2017, at 2:10 PM, Uwe Schindler wrote: > > Hi, > > The other problem is Morphlines. It's not compatible to latest TIKA! I later > versions we removed the Morphlines plugin, but in 5.5 it won't work anymore. > > As far as I see, Solr 5.5 uses TIKA 1.7. I am not sure if this old version > already have MATLAB support - does it contain jmatio.jar? If not, we can > revert both updates: > SOLR-8981 and SOLR-10335 > > Another alternative is to simply remove the MATLAB parser (delete jmatio and > others - look at dependency tree). TIKA disables parsers with classloading > errors automatically. > > I'd really keep the current version, otherwise we have to remove Morphlines. > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > >> -Original Message- >> From: Uwe Schindler [mailto:u...@thetaphi.de] >> Sent: Wednesday, October 18, 2017 8:01 PM >> To: 'dev@lucene.apache.org' >> Subject: RE: Release 5.5.5 >> >> There is still something fishy with 5.5 branch: >> https://jenkins.thetaphi.de/job/Lucene-Solr-5.5- >> Linux/lastCompletedBuild/testReport/org.apache.solr.morphlines.cell/SolrCe >> llMorphlineTest/testSolrCellDocumentTypes2/ >> >> Was this caused by the TIKA updates? >> >> In total there are 6 test failures. >> >> Uwe >> >> - >> Uwe Schindler >> Achterdiek 19, D-28357 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >>> -Original Message- >>> From: Steve Rowe [mailto:sar...@gmail.com] >>> Sent: Tuesday, October 17, 2017 7:39 PM >>> To: Lucene Dev >>> Subject: Release 5.5.5 >>> >>> I think we should release a security-focused 5.5.5. I volunteer to be the >>> release manager. >>> >>> I’ll make an RC later today after I backport issues. >>> >>> -- >>> Steve >>> www.lucidworks.com >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.8.0_144) - Build # 476 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/476/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC
4 tests failed.
FAILED: junit.framework.TestSuite.org.apache.solr.hadoop.MorphlineMapperTest
Error Message:
1 thread leaked from SUITE scope at org.apache.solr.hadoop.MorphlineMapperTest:
1) Thread[id=17, name=Thread-2, state=TIMED_WAITING,
group=TGRP-MorphlineMapperTest] at sun.misc.Unsafe.park(Native Method)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE
scope at org.apache.solr.hadoop.MorphlineMapperTest:
1) Thread[id=17, name=Thread-2, state=TIMED_WAITING,
group=TGRP-MorphlineMapperTest]
at sun.misc.Unsafe.park(Native Method)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
at __randomizedtesting.SeedInfo.seed([999B2F955F1F3060]:0)
FAILED: junit.framework.TestSuite.org.apache.solr.hadoop.MorphlineMapperTest
Error Message:
There are still zombie threads that couldn't be terminated:1) Thread[id=17,
name=Thread-2, state=TIMED_WAITING, group=TGRP-MorphlineMapperTest] at
sun.misc.Unsafe.park(Native Method) at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie
threads that couldn't be terminated:
1) Thread[id=17, name=Thread-2, state=TIMED_WAITING,
group=TGRP-MorphlineMapperTest]
at sun.misc.Unsafe.park(Native Method)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
at __randomizedtesting.SeedInfo.seed([999B2F955F1F3060]:0)
FAILED: org.apache.solr.hadoop.MorphlineMapperTest.testMapper
Error Message:
Cannot instantiate Tika parser: org.apache.tika.parser.crypto.Pkcs7Parser near:
{ #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_999B2F955F1F3060-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
199 # rename "content" field to "text" fields "dateFormats" : [
#
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_999B2F955F1F3060-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
199 "-MM-dd'T'HH:mm:ss", #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_999B2F955F1F3060-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
199 "-MM-dd" ], #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_999B2F955F1F3060-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
198 "fmap" : { #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_999B2F955F1F3060-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
198 "content-type" : "content_type", #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_999B2F955F1F3060-001/tempDir-001/test-morphlines/solr
[JENKINS] Lucene-Solr-Tests-7.x - Build # 187 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/187/ 4 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.test Error Message: Error from server at http://127.0.0.1:33937: At least one of the node(s) specified are not currently active, no action taken. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:33937: At least one of the node(s) specified are not currently active, no action taken. at __randomizedtesting.SeedInfo.seed([84F02A0C6AF774C6:CA415D6C40B193E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:418) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:334) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.ev
[jira] [Commented] (SOLR-11478) Solr should remove itself from live_nodes in zk immediately on shutdown
[ https://issues.apache.org/jira/browse/SOLR-11478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210530#comment-16210530 ] ASF subversion and git services commented on SOLR-11478: Commit 5b04617d67d8585c3bbbdf64e822f2daba1e857d in lucene-solr's branch refs/heads/branch_7x from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5b04617 ] SOLR-11478: Only remove nodeAddedPath node if it exists > Solr should remove itself from live_nodes in zk immediately on shutdown > --- > > Key: SOLR-11478 > URL: https://issues.apache.org/jira/browse/SOLR-11478 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Binoy Dalal >Assignee: Cao Manh Dat >Priority: Minor > Attachments: SOLR-11478.patch > > > Solr currently, upon receiving the stop command, removes its entry from the > zk /live_nodes znode after it has finished processing all inflight requests, > just before finally shutting down. > In this case, any applications that depend on a solr node's live_node entry > to decide whether or not to query it fail once the stop command has been > executed but solr has not yet fully shut down. > Something similar occurs during startup of a solr node. The solr node seems > to add it's entry to the /live_nodes in zk once it is up but before it has > started accepting requests and once again, this causes dependent applications > to fail in a similar fashion. > Hence, removal of the node entry and addition of the same to the zk > live_nodes immediately upon shutting down and at the very end upon coming up > respectively will greatly benefit applications that depend the live_nodes > znode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11478) Solr should remove itself from live_nodes in zk immediately on shutdown
[ https://issues.apache.org/jira/browse/SOLR-11478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210529#comment-16210529 ] ASF subversion and git services commented on SOLR-11478: Commit 99e853faf820b891d577626d30b15a3dfef72970 in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=99e853f ] SOLR-11478: Only remove nodeAddedPath node if it exists > Solr should remove itself from live_nodes in zk immediately on shutdown > --- > > Key: SOLR-11478 > URL: https://issues.apache.org/jira/browse/SOLR-11478 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Binoy Dalal >Assignee: Cao Manh Dat >Priority: Minor > Attachments: SOLR-11478.patch > > > Solr currently, upon receiving the stop command, removes its entry from the > zk /live_nodes znode after it has finished processing all inflight requests, > just before finally shutting down. > In this case, any applications that depend on a solr node's live_node entry > to decide whether or not to query it fail once the stop command has been > executed but solr has not yet fully shut down. > Something similar occurs during startup of a solr node. The solr node seems > to add it's entry to the /live_nodes in zk once it is up but before it has > started accepting requests and once again, this causes dependent applications > to fail in a similar fashion. > Hence, removal of the node entry and addition of the same to the zk > live_nodes immediately upon shutting down and at the very end upon coming up > respectively will greatly benefit applications that depend the live_nodes > znode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20693 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20693/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.solr.cloud.hdfs.HdfsNNFailoverTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:45255 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:45255 at __randomizedtesting.SeedInfo.seed([54AE0B94B655135E:DCFA344E18A97EA6]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrot
[jira] [Commented] (SOLR-11478) Solr should remove itself from live_nodes in zk immediately on shutdown
[ https://issues.apache.org/jira/browse/SOLR-11478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210478#comment-16210478 ] ASF subversion and git services commented on SOLR-11478: Commit 56dee524fec8aa73831a4369740d31bce92f2aa7 in lucene-solr's branch refs/heads/branch_7x from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=56dee52 ] SOLR-11478: Solr should remove itself from live_nodes in zk immediately on shutdown > Solr should remove itself from live_nodes in zk immediately on shutdown > --- > > Key: SOLR-11478 > URL: https://issues.apache.org/jira/browse/SOLR-11478 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Binoy Dalal >Assignee: Cao Manh Dat >Priority: Minor > Attachments: SOLR-11478.patch > > > Solr currently, upon receiving the stop command, removes its entry from the > zk /live_nodes znode after it has finished processing all inflight requests, > just before finally shutting down. > In this case, any applications that depend on a solr node's live_node entry > to decide whether or not to query it fail once the stop command has been > executed but solr has not yet fully shut down. > Something similar occurs during startup of a solr node. The solr node seems > to add it's entry to the /live_nodes in zk once it is up but before it has > started accepting requests and once again, this causes dependent applications > to fail in a similar fashion. > Hence, removal of the node entry and addition of the same to the zk > live_nodes immediately upon shutting down and at the very end upon coming up > respectively will greatly benefit applications that depend the live_nodes > znode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11506) Upgrade ref guide for Json Query DSL
[ https://issues.apache.org/jira/browse/SOLR-11506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210472#comment-16210472 ] ASF subversion and git services commented on SOLR-11506: Commit 72dad7143cf46b69a3586d9a89a13c03d4a855f2 in lucene-solr's branch refs/heads/branch_7x from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=72dad71 ] SOLR-11506: Upgrade ref guide for Json Query DSL > Upgrade ref guide for Json Query DSL > > > Key: SOLR-11506 > URL: https://issues.apache.org/jira/browse/SOLR-11506 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat > Attachments: SOLR-11506.patch, SOLR-11506.patch > > > Json Query DSL needs to be added into ref guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11506) Upgrade ref guide for Json Query DSL
[ https://issues.apache.org/jira/browse/SOLR-11506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210469#comment-16210469 ] ASF subversion and git services commented on SOLR-11506: Commit cdcfc1520d0dab9c1366e1337bc091c3ffc2f5db in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cdcfc15 ] SOLR-11506: Upgrade ref guide for Json Query DSL > Upgrade ref guide for Json Query DSL > > > Key: SOLR-11506 > URL: https://issues.apache.org/jira/browse/SOLR-11506 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat > Attachments: SOLR-11506.patch, SOLR-11506.patch > > > Json Query DSL needs to be added into ref guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11506) Upgrade ref guide for Json Query DSL
[ https://issues.apache.org/jira/browse/SOLR-11506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210471#comment-16210471 ] ASF subversion and git services commented on SOLR-11506: Commit 08f75bec05fa32668db3be6fd6ea06e1d4c9e38b in lucene-solr's branch refs/heads/branch_7_1 from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=08f75be ] SOLR-11506: Upgrade ref guide for Json Query DSL > Upgrade ref guide for Json Query DSL > > > Key: SOLR-11506 > URL: https://issues.apache.org/jira/browse/SOLR-11506 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat > Attachments: SOLR-11506.patch, SOLR-11506.patch > > > Json Query DSL needs to be added into ref guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11490) Add @since javadoc tags to the interesting Solr/Lucene classes
[
https://issues.apache.org/jira/browse/SOLR-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210460#comment-16210460
]
Alexandre Rafalovitch commented on SOLR-11490:
--
Here's what I am getting for Tokenizer factories. Not committing them yet, as
they may have similar issues as mentioned before for Filter factories.
[~rcmuir], any of these look wrong to you, so we could figure out where the
problem exactly is?
{panel}
ClassicTokenizerFactory.java first shows up in 3.1
EdgeNGramTokenizerFactory.java first shows up in 1.2.0
HMMChineseTokenizerFactory.java first shows up in 4.8.0
ICUTokenizerFactory.java first shows up in 3.1
JapaneseTokenizerFactory.java first shows up in 3.6.0
KeywordTokenizerFactory.java first shows up in 1.1.0
LetterTokenizerFactory.java first shows up in 1.1.0
LowerCaseTokenizerFactory.java first shows up in 1.1.0
NGramTokenizerFactory.java first shows up in 1.2.0
PathHierarchyTokenizerFactory.java first shows up in 3.1
PatternTokenizerFactory.java first shows up in solr1.2
SimplePatternSplitTokenizerFactory.java first shows up in 6.5.0
SimplePatternTokenizerFactory.java first shows up in 6.5.0
StandardTokenizerFactory.java first shows up in 1.1.0
ThaiTokenizerFactory.java first shows up in 4.8.0
TokenizerFactory.java first shows up in 1.1.0
UAX29URLEmailTokenizerFactory.java first shows up in 3.1
UIMAAnnotationsTokenizerFactory.java first shows up in 4.0.0
UIMATypeAwareAnnotationsTokenizerFactory.java first shows up in 4.0.0
WhitespaceTokenizerFactory.java first shows up in 1.1.0
WikipediaTokenizerFactory.java first shows up in 3.1
{panel}
Note, PatternTokenizerFactory already has a @since tag, which is why it looks
different from those proposed automatically.
> Add @since javadoc tags to the interesting Solr/Lucene classes
> --
>
> Key: SOLR-11490
> URL: https://issues.apache.org/jira/browse/SOLR-11490
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> As per the discussion on the dev list, it may be useful to add Javadoc since
> tags to significant (or even all) Java files.
> For user-facing files (such as analyzers, URPs, stream evaluators, etc) it
> would be useful when trying to identifying whether a particular class only
> comes later than user's particular version.
> For other classes, it may be useful for historical reasons.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11490) Add @since javadoc tags to the interesting Solr/Lucene classes
[ https://issues.apache.org/jira/browse/SOLR-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210444#comment-16210444 ] ASF subversion and git services commented on SOLR-11490: Commit a69a519de5e508f7073ef4e01b1e2c34ea8032bf in lucene-solr's branch refs/heads/branch_7x from [~arafalov] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a69a519 ] SOLR-11490: Add missing @since tags To all descendants of TupleStream (cherry picked from commit 70784f456119e44e936d058c541945ebec0efaff) > Add @since javadoc tags to the interesting Solr/Lucene classes > -- > > Key: SOLR-11490 > URL: https://issues.apache.org/jira/browse/SOLR-11490 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > > As per the discussion on the dev list, it may be useful to add Javadoc since > tags to significant (or even all) Java files. > For user-facing files (such as analyzers, URPs, stream evaluators, etc) it > would be useful when trying to identifying whether a particular class only > comes later than user's particular version. > For other classes, it may be useful for historical reasons. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11490) Add @since javadoc tags to the interesting Solr/Lucene classes
[ https://issues.apache.org/jira/browse/SOLR-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210443#comment-16210443 ] ASF subversion and git services commented on SOLR-11490: Commit 70784f456119e44e936d058c541945ebec0efaff in lucene-solr's branch refs/heads/master from [~arafalov] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=70784f4 ] SOLR-11490: Add missing @since tags To all descendants of TupleStream > Add @since javadoc tags to the interesting Solr/Lucene classes > -- > > Key: SOLR-11490 > URL: https://issues.apache.org/jira/browse/SOLR-11490 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > > As per the discussion on the dev list, it may be useful to add Javadoc since > tags to significant (or even all) Java files. > For user-facing files (such as analyzers, URPs, stream evaluators, etc) it > would be useful when trying to identifying whether a particular class only > comes later than user's particular version. > For other classes, it may be useful for historical reasons. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2125 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2125/ 5 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling Error Message: Both triggers should have fired by now Stack Trace: java.lang.AssertionError: Both triggers should have fired by now at __randomizedtesting.SeedInfo.seed([6D999028E1166D4F:96BB380D33BC8EDD]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testTriggerThrottling(TriggerIntegrationTest.java:194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption Error Message: Could not load collection from ZK: overwrite Stack Trace: org.apache.solr.common.SolrException: Could not load collection from ZK: overwrite at __randomizedtesting.SeedInfo.seed([1DCA8860397DC6D8:F1F1698B572DB90E]:0) at org.apache.solr.
[jira] [Commented] (SOLR-11512) Query parsing should not loop forever with 100% cpu
[
https://issues.apache.org/jira/browse/SOLR-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210438#comment-16210438
]
Yonik Seeley commented on SOLR-11512:
-
Interesting... this is probably due to edismax trying to parse as-is, catching
any exceptions, and then trying more aggressive escaping to try and prevent the
parse exception.
Definitely specific to edismax, but I wouldn't have thought it would somehow
bypass the infinite recursion checker.
> Query parsing should not loop forever with 100% cpu
> ---
>
> Key: SOLR-11512
> URL: https://issues.apache.org/jira/browse/SOLR-11512
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Will Currie
>Priority: Minor
>
> The following query against the techproducts example puts solr into an
> infinite loop:
> {noformat}
> curl -g -v
> 'http://localhost:8983/solr/techproducts/select?q=*&defType=edismax&qq={!edismax+v=something}&bq={!edismax+v=$qq}
> {noformat}
> Problem doesn't depend on the collection, just an easy example. I guess I'd
> expect a failure with "Infinite Recursion detected parsing query ..."
> instead. So depending on the query config a user typing {!edismax v=whatever}
> into a search box can send a solr instance to 100% cpu.
> I can reproduce using TestExtendedDismaxParser by adding:
> {code}
> @Test
> public void loopsForever() throws Exception {
> assertJQ(req("defType", "edismax", "q", "*", "qq", "{!edismax
> v=something}", "bq", "{!edismax v=$qq}"));
> }
> {code}
> The code seems to hit QParser.checkRecurse() and try to fail but something
> sends it around for another try. Repeat.
> Given the complexity of the parsing code there may well be other examples.
> There's no way to disable the local params syntax is there? Question was
> asked in SOLR-4197.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 254 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/254/ Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:62543/ou_vg/lk Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:62543/ou_vg/lk at __randomizedtesting.SeedInfo.seed([6958EA641D73E635:E10CD5BEB38F8BCD]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSu
[GitHub] lucene-solr pull request #264: Fix NPE on connection failure
GitHub user SerCeMan opened a pull request: https://github.com/apache/lucene-solr/pull/264 Fix NPE on connection failure We're using ZK for node discovery. During rare evens of when some nodes are unavailable, we observe NPEs. I'm not quite familiar with the solr client logic but by looking at the code further, I concluded that the iteration misses a null check. ```java java.lang.NullPointerException: null at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1143) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1037) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:974) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:990) at com.canva.search.SolrQueryServiceImpl.query(SolrQueryServiceImpl.java:65) at com.canva.search.SolrQueryServiceImpl.query(SolrQueryServiceImpl.java:50) at com.canva.search.server.SearchServiceServer.searchMedia(SearchServiceServer.java:358) at com.canva.search.server.FinagleSearchServer.searchMedia(FinagleSearchServer.java:97) at com.canva.search.server.FinagleSearchServer.doApply(FinagleSearchServer.java:63) at com.canva.http.AbstractFinagleServer.doApply0(AbstractFinagleServer.java:321) at com.canva.http.AbstractFinagleServer.lambda$apply$1(AbstractFinagleServer.java:279) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/SerCeMan/lucene-solr patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/264.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #264 commit 093e63533bc71c1e7c65709d05746b7d7b1a0a13 Author: Sergey Tselovalnikov Date: 2017-10-19T01:25:50Z Fix NPE on connection failure --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11506) Upgrade ref guide for Json Query DSL
[ https://issues.apache.org/jira/browse/SOLR-11506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210426#comment-16210426 ] Cao Manh Dat commented on SOLR-11506: - Thank [~ctargett], I will commit now. > Upgrade ref guide for Json Query DSL > > > Key: SOLR-11506 > URL: https://issues.apache.org/jira/browse/SOLR-11506 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat > Attachments: SOLR-11506.patch, SOLR-11506.patch > > > Json Query DSL needs to be added into ref guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11512) Query parsing should not loop forever with 100% cpu
[
https://issues.apache.org/jira/browse/SOLR-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Currie updated SOLR-11512:
---
Description:
The following query against the techproducts example puts solr into an infinite
loop:
{noformat}
curl -g -v
'http://localhost:8983/solr/techproducts/select?q=*&defType=edismax&qq={!edismax+v=something}&bq={!edismax+v=$qq}
{noformat}
Problem doesn't depend on the collection, just an easy example. I guess I'd
expect a failure with "Infinite Recursion detected parsing query ..." instead.
So depending on the query config a user typing {!edismax v=whatever} into a
search box can send a solr instance to 100% cpu.
I can reproduce using TestExtendedDismaxParser by adding:
{code}
@Test
public void loopsForever() throws Exception {
assertJQ(req("defType", "edismax", "q", "*", "qq", "{!edismax
v=something}", "bq", "{!edismax v=$qq}"));
}
{code}
The code seems to hit QParser.checkRecurse() and try to fail but something
sends it around for another try. Repeat.
Given the complexity of the parsing code there may well be other examples.
There's no way to disable the local params syntax is there? Question was asked
in SOLR-4197.
was:
The following query against the techproducts puts solr into an infinite loop:
{noformat}
curl -g -v
'http://localhost:8983/solr/techproducts/select?q=*&defType=edismax&qq={!edismax+v=something}&bq={!edismax+v=$qq}
{noformat}
I guess I'd expect a failure with "Infinite Recursion detected parsing query
..." instead. So depending on the query config a user typing {!edismax
v=whatever} into a search box can send a solr instance to 100% cpu.
I can reproduce using TestExtendedDismaxParser by adding:
{code}
@Test
public void loopsForever() throws Exception {
assertJQ(req("defType", "edismax", "q", "*", "qq", "{!edismax
v=something}", "bq", "{!edismax v=$qq}"));
}
{code}
The code seems to hit QParser.checkRecurse() and try to fail but something
sends it around for another try. Repeat.
Given the complexity of the parsing code there may well be other examples.
There's no way to disable the local params syntax is there? Question was asked
in SOLR-4197.
> Query parsing should not loop forever with 100% cpu
> ---
>
> Key: SOLR-11512
> URL: https://issues.apache.org/jira/browse/SOLR-11512
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Will Currie
>Priority: Minor
>
> The following query against the techproducts example puts solr into an
> infinite loop:
> {noformat}
> curl -g -v
> 'http://localhost:8983/solr/techproducts/select?q=*&defType=edismax&qq={!edismax+v=something}&bq={!edismax+v=$qq}
> {noformat}
> Problem doesn't depend on the collection, just an easy example. I guess I'd
> expect a failure with "Infinite Recursion detected parsing query ..."
> instead. So depending on the query config a user typing {!edismax v=whatever}
> into a search box can send a solr instance to 100% cpu.
> I can reproduce using TestExtendedDismaxParser by adding:
> {code}
> @Test
> public void loopsForever() throws Exception {
> assertJQ(req("defType", "edismax", "q", "*", "qq", "{!edismax
> v=something}", "bq", "{!edismax v=$qq}"));
> }
> {code}
> The code seems to hit QParser.checkRecurse() and try to fail but something
> sends it around for another try. Repeat.
> Given the complexity of the parsing code there may well be other examples.
> There's no way to disable the local params syntax is there? Question was
> asked in SOLR-4197.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11512) Query parsing should not loop forever with 100% cpu
Will Currie created SOLR-11512:
--
Summary: Query parsing should not loop forever with 100% cpu
Key: SOLR-11512
URL: https://issues.apache.org/jira/browse/SOLR-11512
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Reporter: Will Currie
Priority: Minor
The following query against the techproducts puts solr into an infinite loop:
{noformat}
curl -g -v
'http://localhost:8983/solr/techproducts/select?q=*&defType=edismax&qq={!edismax+v=something}&bq={!edismax+v=$qq}
{noformat}
I guess I'd expect a failure with "Infinite Recursion detected parsing query
..." instead. So depending on the query config a user typing {!edismax
v=whatever} into a search box can send a solr instance to 100% cpu.
I can reproduce using TestExtendedDismaxParser by adding:
{code}
@Test
public void loopsForever() throws Exception {
assertJQ(req("defType", "edismax", "q", "*", "qq", "{!edismax
v=something}", "bq", "{!edismax v=$qq}"));
}
{code}
The code seems to hit QParser.checkRecurse() and try to fail but something
sends it around for another try. Repeat.
Given the complexity of the parsing code there may well be other examples.
There's no way to disable the local params syntax is there? Question was asked
in SOLR-4197.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11464) Unused code in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-11464. - Resolution: Fixed Fix Version/s: 7.2 > Unused code in DistributedUpdateProcessor > - > > Key: SOLR-11464 > URL: https://issues.apache.org/jira/browse/SOLR-11464 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Assignee: David Smiley >Priority: Minor > Fix For: 7.2 > > Attachments: SOLR-11464.patch, > SOLR_11464_SOLR_11493_DistributedUrp.patch, unused.png > > > While reading code I ran across a couple of suspicious unused > values/variables. Thought I would raise this so that folks can consider if > something was lost here, or if perhaps we can eliminate an unnecessary call > to zookeeper and tidy things up a bit. Screenshot and patch to eliminate > shortly... -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11493) Unnecessary creation of singlton lists in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-11493. - Resolution: Fixed Fix Version/s: 7.2 Thanks Gus! More valuable to me here is reducing needless LOC. All tests pass (including SOLR-11444 and SOLR-11464 included). > Unnecessary creation of singlton lists in DistributedUpdateProcessor > > > Key: SOLR-11493 > URL: https://issues.apache.org/jira/browse/SOLR-11493 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Gus Heck >Assignee: David Smiley >Priority: Minor > Fix For: 7.2 > > Attachments: SOLR-11493.patch > > > I thought I'd found another bug because one of 4 variants didn't have a loop, > but then I noticed that the method in question was being fed a list, and the > very first thing it does is loop that list... so it seems there is no need to > loop the list, create and pass in a singleton list, and then have the method > loop that singleton list to process a single item... > Fixing this should save us a bit of object creation & therefore reduce GC > load. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11493) Unnecessary creation of singlton lists in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210372#comment-16210372 ] ASF subversion and git services commented on SOLR-11493: Commit d71df4c24a208562738d86c533d73ab9a619933a in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d71df4c ] SOLR-11464: SOLR-11493: Minor refactorings to DistributedUpdateProcessor (cherry picked from commit 18c8091da5a35d6b0c19253b181b9e2468cd0a37) > Unnecessary creation of singlton lists in DistributedUpdateProcessor > > > Key: SOLR-11493 > URL: https://issues.apache.org/jira/browse/SOLR-11493 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Gus Heck >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-11493.patch > > > I thought I'd found another bug because one of 4 variants didn't have a loop, > but then I noticed that the method in question was being fed a list, and the > very first thing it does is loop that list... so it seems there is no need to > loop the list, create and pass in a singleton list, and then have the method > loop that singleton list to process a single item... > Fixing this should save us a bit of object creation & therefore reduce GC > load. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11464) Unused code in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210371#comment-16210371 ] ASF subversion and git services commented on SOLR-11464: Commit d71df4c24a208562738d86c533d73ab9a619933a in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d71df4c ] SOLR-11464: SOLR-11493: Minor refactorings to DistributedUpdateProcessor (cherry picked from commit 18c8091da5a35d6b0c19253b181b9e2468cd0a37) > Unused code in DistributedUpdateProcessor > - > > Key: SOLR-11464 > URL: https://issues.apache.org/jira/browse/SOLR-11464 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-11464.patch, > SOLR_11464_SOLR_11493_DistributedUrp.patch, unused.png > > > While reading code I ran across a couple of suspicious unused > values/variables. Thought I would raise this so that folks can consider if > something was lost here, or if perhaps we can eliminate an unnecessary call > to zookeeper and tidy things up a bit. Screenshot and patch to eliminate > shortly... -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11493) Unnecessary creation of singlton lists in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210364#comment-16210364 ] ASF subversion and git services commented on SOLR-11493: Commit 18c8091da5a35d6b0c19253b181b9e2468cd0a37 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=18c8091 ] SOLR-11464: SOLR-11493: Minor refactorings to DistributedUpdateProcessor > Unnecessary creation of singlton lists in DistributedUpdateProcessor > > > Key: SOLR-11493 > URL: https://issues.apache.org/jira/browse/SOLR-11493 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Gus Heck >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-11493.patch > > > I thought I'd found another bug because one of 4 variants didn't have a loop, > but then I noticed that the method in question was being fed a list, and the > very first thing it does is loop that list... so it seems there is no need to > loop the list, create and pass in a singleton list, and then have the method > loop that singleton list to process a single item... > Fixing this should save us a bit of object creation & therefore reduce GC > load. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11464) Unused code in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210363#comment-16210363 ] ASF subversion and git services commented on SOLR-11464: Commit 18c8091da5a35d6b0c19253b181b9e2468cd0a37 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=18c8091 ] SOLR-11464: SOLR-11493: Minor refactorings to DistributedUpdateProcessor > Unused code in DistributedUpdateProcessor > - > > Key: SOLR-11464 > URL: https://issues.apache.org/jira/browse/SOLR-11464 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-11464.patch, > SOLR_11464_SOLR_11493_DistributedUrp.patch, unused.png > > > While reading code I ran across a couple of suspicious unused > values/variables. Thought I would raise this so that folks can consider if > something was lost here, or if perhaps we can eliminate an unnecessary call > to zookeeper and tidy things up a bit. Screenshot and patch to eliminate > shortly... -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 628 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/628/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.cloud.hdfs.StressHdfsTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:43077/h Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:43077/h at __randomizedtesting.SeedInfo.seed([A7724E0E4D8D9A32:2F2671D4E371F7CA]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carr
[jira] [Updated] (SOLR-11511) Use existing private field in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated SOLR-11511: Attachment: SOLR-11511.patch > Use existing private field in DistributedUpdateProcessor > > > Key: SOLR-11511 > URL: https://issues.apache.org/jira/browse/SOLR-11511 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck > Attachments: SOLR-11511.patch > > > The DistributedUpdateProcessor has a private instance field called cloudDesc. > It is used in a few places, but most code navigates to CloudDescriptor from > the request object instead. > The fundamental question of this ticket, is this: is there any reason to > distrust this field and do the navigation directly (in which case maybe we > get rid of the field instead?) or can we trust it and thus should use it > where we can. Since it is a private field only ever updated in the > constructor, it's not likely to be changing out from under us. The request > from which it is derived is also held in a private final field, so it very > much looks to me like this field should have been final and should be used. > This might or might not be a performance gain (depending on whether or not > the compiler can optimize away something like this already), but it will be a > readability and consistency gain for sure. > Attaching patch to tidy this up shortly... > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.5-Windows (32bit/jdk1.8.0_144) - Build # 144 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Windows/144/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 4 object(s) that were not released!!! [TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([E44690A17EBB85CE]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238) at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) 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:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) 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:367) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_E44690A17EBB85CE-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_E44690A17EBB85CE-001\tempDir-001\node2\testschemaapi_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-5.5-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_E44690A17EBB85CE-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_E44690A17EBB85CE-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_E44690A17EBB85CE-001\tempDir-001\node2\testschemaapi_shard1_replica2\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_E44690A17EBB85CE-001\tempDir-001\node2\testschemaapi_shard1_replica2\data C:\Users\jenkins\workspace\Lucene-Solr-5.5-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_E44690A17EBB85CE-001\tempDir-001\node2\testschemaapi_shard1_replica2: java.nio.file.DirectoryNotEmptyException: C:
[jira] [Updated] (SOLR-11511) Use existing private field in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated SOLR-11511: Description: The DistributedUpdateProcessor has a private instance field called cloudDesc. It is used in a few places, but most code navigates to CloudDescriptor from the request object instead. The fundamental question of this ticket, is this: is there any reason to distrust this field and do the navigation directly (in which case maybe we get rid of the field instead?) or can we trust it and thus should use it where we can. Since it is a private field only ever updated in the constructor, it's not likely to be changing out from under us. The request from which it is derived is also held in a private final field, so it very much looks to me like this field should have been final and should be used. This might or might not be a performance gain (depending on whether or not the compiler can optimize away something like this already), but it will be a readability and consistency gain for sure. Attaching patch to tidy this up shortly... was: The DistributedUpdateProcessor has a private instance field called cloudDesc. It is used in a few places, but most code navigates to CoreDescriptor from the request object instead. The fundamental question of this ticket, is this: is there any reason to distrust this field and do the navigation directly (in which case maybe we get rid of the field instead?) or can we trust it and thus should use it where we can. Since it is a private field only ever updated in the constructor, it's not likely to be changing out from under us. The request from which it is derived is also held in a private final field, so it very much looks to me like this field should have been final and should be used. This might or might not be a performance gain (depending on whether or not the compiler can optimize away something like this already), but it will be a readability and consistency gain for sure. Attaching patch to tidy this up shortly... > Use existing private field in DistributedUpdateProcessor > > > Key: SOLR-11511 > URL: https://issues.apache.org/jira/browse/SOLR-11511 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck > > The DistributedUpdateProcessor has a private instance field called cloudDesc. > It is used in a few places, but most code navigates to CloudDescriptor from > the request object instead. > The fundamental question of this ticket, is this: is there any reason to > distrust this field and do the navigation directly (in which case maybe we > get rid of the field instead?) or can we trust it and thus should use it > where we can. Since it is a private field only ever updated in the > constructor, it's not likely to be changing out from under us. The request > from which it is derived is also held in a private final field, so it very > much looks to me like this field should have been final and should be used. > This might or might not be a performance gain (depending on whether or not > the compiler can optimize away something like this already), but it will be a > readability and consistency gain for sure. > Attaching patch to tidy this up shortly... > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11511) Use existing private field in DistributedUpdateProcessor
Gus Heck created SOLR-11511: --- Summary: Use existing private field in DistributedUpdateProcessor Key: SOLR-11511 URL: https://issues.apache.org/jira/browse/SOLR-11511 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: master (8.0) Reporter: Gus Heck The DistributedUpdateProcessor has a private instance field called coreDesc. It is used in a few places, but most code navigates to CoreDescriptor from the request object instead. The fundamental question of this ticket, is this: is there any reason to distrust this field and do the navigation directly (in which case maybe we get rid of the field instead?) or can we trust it and thus should use it where we can. Since it is a private field only ever updated in the constructor, it's not likely to be changing out from under us. The request from which it is derived is also held in a private final field, so it very much looks to me like this field should have been final and should be used. This might or might not be a performance gain (depending on whether or not the compiler can optimize away something like this already), but it will be a readability and consistency gain for sure. Attaching patch to tidy this up shortly... -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11511) Use existing private field in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated SOLR-11511: Description: The DistributedUpdateProcessor has a private instance field called cloudDesc. It is used in a few places, but most code navigates to CoreDescriptor from the request object instead. The fundamental question of this ticket, is this: is there any reason to distrust this field and do the navigation directly (in which case maybe we get rid of the field instead?) or can we trust it and thus should use it where we can. Since it is a private field only ever updated in the constructor, it's not likely to be changing out from under us. The request from which it is derived is also held in a private final field, so it very much looks to me like this field should have been final and should be used. This might or might not be a performance gain (depending on whether or not the compiler can optimize away something like this already), but it will be a readability and consistency gain for sure. Attaching patch to tidy this up shortly... was: The DistributedUpdateProcessor has a private instance field called coreDesc. It is used in a few places, but most code navigates to CoreDescriptor from the request object instead. The fundamental question of this ticket, is this: is there any reason to distrust this field and do the navigation directly (in which case maybe we get rid of the field instead?) or can we trust it and thus should use it where we can. Since it is a private field only ever updated in the constructor, it's not likely to be changing out from under us. The request from which it is derived is also held in a private final field, so it very much looks to me like this field should have been final and should be used. This might or might not be a performance gain (depending on whether or not the compiler can optimize away something like this already), but it will be a readability and consistency gain for sure. Attaching patch to tidy this up shortly... > Use existing private field in DistributedUpdateProcessor > > > Key: SOLR-11511 > URL: https://issues.apache.org/jira/browse/SOLR-11511 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck > > The DistributedUpdateProcessor has a private instance field called cloudDesc. > It is used in a few places, but most code navigates to CoreDescriptor from > the request object instead. > The fundamental question of this ticket, is this: is there any reason to > distrust this field and do the navigation directly (in which case maybe we > get rid of the field instead?) or can we trust it and thus should use it > where we can. Since it is a private field only ever updated in the > constructor, it's not likely to be changing out from under us. The request > from which it is derived is also held in a private final field, so it very > much looks to me like this field should have been final and should be used. > This might or might not be a performance gain (depending on whether or not > the compiler can optimize away something like this already), but it will be a > readability and consistency gain for sure. > Attaching patch to tidy this up shortly... > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11510) Ref Guide: Improve DIH docs around encrypting the password
[ https://issues.apache.org/jira/browse/SOLR-11510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-11510. -- Resolution: Fixed > Ref Guide: Improve DIH docs around encrypting the password > -- > > Key: SOLR-11510 > URL: https://issues.apache.org/jira/browse/SOLR-11510 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Fix For: 7.1 > > > A user pointed me to the below StackOverflow question and suggested we could > improve the DIH docs around encrypted passwords a bit. He's right - there is > only a side comment that suggests how one could do it and it should have a > better section highlighting how to configure it. > https://stackoverflow.com/questions/46819637/how-do-you-encrypt-the-databse-password-used-by-solrs-datainputhandler-dih/46819643#46819643 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11510) Ref Guide: Improve DIH docs around encrypting the password
[ https://issues.apache.org/jira/browse/SOLR-11510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett reassigned SOLR-11510: Assignee: Cassandra Targett > Ref Guide: Improve DIH docs around encrypting the password > -- > > Key: SOLR-11510 > URL: https://issues.apache.org/jira/browse/SOLR-11510 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett > Fix For: 7.1 > > > A user pointed me to the below StackOverflow question and suggested we could > improve the DIH docs around encrypted passwords a bit. He's right - there is > only a side comment that suggests how one could do it and it should have a > better section highlighting how to configure it. > https://stackoverflow.com/questions/46819637/how-do-you-encrypt-the-databse-password-used-by-solrs-datainputhandler-dih/46819643#46819643 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11510) Ref Guide: Improve DIH docs around encrypting the password
[ https://issues.apache.org/jira/browse/SOLR-11510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210304#comment-16210304 ] ASF subversion and git services commented on SOLR-11510: Commit ab1fa1adbdbc6a76ffd231f802b3626369f34936 in lucene-solr's branch refs/heads/branch_7x from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ab1fa1a ] SOLR-11510: improve DIH docs for using an encrypted password. > Ref Guide: Improve DIH docs around encrypting the password > -- > > Key: SOLR-11510 > URL: https://issues.apache.org/jira/browse/SOLR-11510 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Fix For: 7.1 > > > A user pointed me to the below StackOverflow question and suggested we could > improve the DIH docs around encrypted passwords a bit. He's right - there is > only a side comment that suggests how one could do it and it should have a > better section highlighting how to configure it. > https://stackoverflow.com/questions/46819637/how-do-you-encrypt-the-databse-password-used-by-solrs-datainputhandler-dih/46819643#46819643 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11510) Ref Guide: Improve DIH docs around encrypting the password
[ https://issues.apache.org/jira/browse/SOLR-11510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210305#comment-16210305 ] ASF subversion and git services commented on SOLR-11510: Commit 349cf663b0ce99969db3db52e9aeac201c8e479d in lucene-solr's branch refs/heads/branch_7_1 from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=349cf66 ] SOLR-11510: improve DIH docs for using an encrypted password. > Ref Guide: Improve DIH docs around encrypting the password > -- > > Key: SOLR-11510 > URL: https://issues.apache.org/jira/browse/SOLR-11510 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Fix For: 7.1 > > > A user pointed me to the below StackOverflow question and suggested we could > improve the DIH docs around encrypted passwords a bit. He's right - there is > only a side comment that suggests how one could do it and it should have a > better section highlighting how to configure it. > https://stackoverflow.com/questions/46819637/how-do-you-encrypt-the-databse-password-used-by-solrs-datainputhandler-dih/46819643#46819643 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11510) Ref Guide: Improve DIH docs around encrypting the password
[ https://issues.apache.org/jira/browse/SOLR-11510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210302#comment-16210302 ] ASF subversion and git services commented on SOLR-11510: Commit a37c4b5ff19637d7050bc54d52d12183511b384f in lucene-solr's branch refs/heads/master from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a37c4b5 ] SOLR-11510: improve DIH docs for using an encrypted password. > Ref Guide: Improve DIH docs around encrypting the password > -- > > Key: SOLR-11510 > URL: https://issues.apache.org/jira/browse/SOLR-11510 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Fix For: 7.1 > > > A user pointed me to the below StackOverflow question and suggested we could > improve the DIH docs around encrypted passwords a bit. He's right - there is > only a side comment that suggests how one could do it and it should have a > better section highlighting how to configure it. > https://stackoverflow.com/questions/46819637/how-do-you-encrypt-the-databse-password-used-by-solrs-datainputhandler-dih/46819643#46819643 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11492) More Modern cloud dev script
[ https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210273#comment-16210273 ] Gus Heck commented on SOLR-11492: - Ah good find... that seem to also work on ubuntu linux so I'll go with that > More Modern cloud dev script > > > Key: SOLR-11492 > URL: https://issues.apache.org/jira/browse/SOLR-11492 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Priority: Minor > Attachments: cloud.sh > > > Most of the scripts in solr/cloud-dev do things like start using java -jar > and other similarly ancient techniques. I recently decided I really didn't > like that it was a pain to setup a cloud to test a patch/feature and that > often one winds up needing to blow away existing testing so working on more > than one thing at a time is irritating... so here's a script I wrote, if > folks like it I'd be happy for it to be included in solr/cloud-dev -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11510) Ref Guide: Improve DIH docs around encrypting the password
Cassandra Targett created SOLR-11510: Summary: Ref Guide: Improve DIH docs around encrypting the password Key: SOLR-11510 URL: https://issues.apache.org/jira/browse/SOLR-11510 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Cassandra Targett Fix For: 7.1 A user pointed me to the below StackOverflow question and suggested we could improve the DIH docs around encrypted passwords a bit. He's right - there is only a side comment that suggests how one could do it and it should have a better section highlighting how to configure it. https://stackoverflow.com/questions/46819637/how-do-you-encrypt-the-databse-password-used-by-solrs-datainputhandler-dih/46819643#46819643 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11492) More Modern cloud dev script
[ https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated SOLR-11492: Attachment: cloud.sh > More Modern cloud dev script > > > Key: SOLR-11492 > URL: https://issues.apache.org/jira/browse/SOLR-11492 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (8.0) >Reporter: Gus Heck >Priority: Minor > Attachments: cloud.sh, cloud.sh > > > Most of the scripts in solr/cloud-dev do things like start using java -jar > and other similarly ancient techniques. I recently decided I really didn't > like that it was a pain to setup a cloud to test a patch/feature and that > often one winds up needing to blow away existing testing so working on more > than one thing at a time is irritating... so here's a script I wrote, if > folks like it I'd be happy for it to be included in solr/cloud-dev -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11446) Heavily edit the "near real time searching" page in the reference guide
[ https://issues.apache.org/jira/browse/SOLR-11446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210266#comment-16210266 ] ASF subversion and git services commented on SOLR-11446: Commit 9e4e366f5b744e8efedaa0a849324b070811aba8 in lucene-solr's branch refs/heads/branch_7x from [~erickerickson] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9e4e366 ] SOLR-11446: Heavily edit the 'near real time searching' page in the reference guide, fix doc build error (cherry picked from commit 57aecde) > Heavily edit the "near real time searching" page in the reference guide > --- > > Key: SOLR-11446 > URL: https://issues.apache.org/jira/browse/SOLR-11446 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11446.patch > > > That page needs some focus, I'll attach a draft in a second (edited late last > night and not proofread yet). > Feedback welcome -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11446) Heavily edit the "near real time searching" page in the reference guide
[ https://issues.apache.org/jira/browse/SOLR-11446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210265#comment-16210265 ] ASF subversion and git services commented on SOLR-11446: Commit 57aecde244764c16ee2d5b51cfb2676707d79e57 in lucene-solr's branch refs/heads/master from [~erickerickson] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=57aecde ] SOLR-11446: Heavily edit the 'near real time searching' page in the reference guide, fix doc build error > Heavily edit the "near real time searching" page in the reference guide > --- > > Key: SOLR-11446 > URL: https://issues.apache.org/jira/browse/SOLR-11446 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11446.patch > > > That page needs some focus, I'll attach a draft in a second (edited late last > night and not proofread yet). > Feedback welcome -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-reference-guide-master - Build # 2692 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-master/2692/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision c6ed9f14ec214de8e2314ed77ced7b4e2a6de30b
(refs/remotes/origin/master)
Commit message: "SOLR-11446: Heavily edit the 'near real time searching' page
in the reference guide"
> git config core.sparsecheckout # timeout=10
> git checkout -f c6ed9f14ec214de8e2314ed77ced7b4e2a6de30b
> git rev-list c6ed9f14ec214de8e2314ed77ced7b4e2a6de30b # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash
/tmp/jenkins3101771579277589276.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17 0311 3804 BB82 D39D C0E3
Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36 166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'
Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.
Upgrade Notes:
* No new notes to display.
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset wrappers
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 2 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
+ ant clean build-site build-pdf
Buildfile:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml
clean:
build-init:
[mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
[echo] Copying all non template files from src ...
[copy] Copying 371 files to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
[echo] Copy (w/prop replacement) any template files from src...
[copy] Copying 1 file to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.
-ivy-fail-disallowed-ivy-version:
ivy-fail:
ivy-configure:
[ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 ::
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/lucene/top-level-ivy-settings.xml
resolve:
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] ERRORS
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver
[JENKINS] Lucene-Solr-Tests-5.5 - Build # 32 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5/32/ 6 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=10687, name=collection1, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=10687, name=collection1, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:47114/jiojw/w: collection already exists: awholynewstresscollection_collection1_0 at __randomizedtesting.SeedInfo.seed([C2EBF582321F93BF]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:577) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:891) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:827) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1575) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1596) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:984) FAILED: org.apache.solr.cloud.TestStressLiveNodes.testStress Error Message: iter125 21 != 8 expected:<[127.0.0.1:56203_solr, thrasher-T125_0-0, thrasher-T125_0-1, thrasher-T125_0-2, thrasher-T125_0-3, thrasher-T125_1-0, thrasher-T125_1-1, thrasher-T125_1-2, thrasher-T125_1-3, thrasher-T125_2-0, thrasher-T125_2-1, thrasher-T125_2-2, thrasher-T125_2-3, thrasher-T125_3-0, thrasher-T125_3-1, thrasher-T125_3-2, thrasher-T125_3-3, thrasher-T125_4-0, thrasher-T125_4-1, thrasher-T125_4-2, thrasher-T125_4-3]> but was:<[127.0.0.1:56203_solr, thrasher-T125_0-0, thrasher-T125_0-1, thrasher-T125_0-2, thrasher-T125_0-3, thrasher-T125_1-0, thrasher-T125_1-1, thrasher-T125_1-2]> Stack Trace: java.lang.AssertionError: iter125 21 != 8 expected:<[127.0.0.1:56203_solr, thrasher-T125_0-0, thrasher-T125_0-1, thrasher-T125_0-2, thrasher-T125_0-3, thrasher-T125_1-0, thrasher-T125_1-1, thrasher-T125_1-2, thrasher-T125_1-3, thrasher-T125_2-0, thrasher-T125_2-1, thrasher-T125_2-2, thrasher-T125_2-3, thrasher-T125_3-0, thrasher-T125_3-1, thrasher-T125_3-2, thrasher-T125_3-3, thrasher-T125_4-0, thrasher-T125_4-1, thrasher-T125_4-2, thrasher-T125_4-3]> but was:<[127.0.0.1:56203_solr, thrasher-T125_0-0, thrasher-T125_0-1, thrasher-T125_0-2, thrasher-T125_0-3, thrasher-T125_1-0, thrasher-T125_1-1, thrasher-T125_1-2]> at __randomizedtesting.SeedInfo.seed([C2EBF582321F93BF:D7F08843B1E86BC4]: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.cloud.TestStressLiveNodes.testStress(TestStressLiveNodes.java:200) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) 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.
[jira] [Updated] (SOLR-11326) CDCR bootstrap should not download tlog's from source
[
https://issues.apache.org/jira/browse/SOLR-11326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-11326:
-
Attachment: SOLR-11326.patch
Made some tweaks to the patch. I think it's ready.
I'll do another round of review and tests before committing it
> CDCR bootstrap should not download tlog's from source
> -
>
> Key: SOLR-11326
> URL: https://issues.apache.org/jira/browse/SOLR-11326
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11326.patch, SOLR-11326.patch, SOLR-11326.patch,
> SOLR-11326.patch, WITHOUT-FIX.patch
>
>
> While analyzing two separate fails on SOLR-11278 I see that during bootstrap
> the tlog's from the source is getting download
> snippet1:
> {code}
>[junit4] 2> 42931 INFO (qtp1525032019-69) [n:127.0.0.1:53178_solr
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1]
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor
>[junit4] 2> 42934 INFO
> (cdcr-bootstrap-status-32-thread-1-processing-n:127.0.0.1:53178_solr
> x:cdcr-source_shard1_replica1 s:shard1 c:cdcr-source r:core_node1)
> [n:127.0.0.1:53178_solr c:cdcr-source s:shard1 r:core_node1
> x:cdcr-source_shard1_replica1] o.a.s.h.CdcrReplicatorManager Attempting to
> bootstrap target collection: cdcr-target shard: shard1 leader:
> http://127.0.0.1:53170/solr/cdcr-target_shard1_replica1/
>[junit4] 2> 43003 INFO (qtp1525032019-69) [n:127.0.0.1:53178_solr
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1]
> o.a.s.c.S.Request [cdcr-source_shard1_replica1] webapp=/solr
> path=/replication
> params={qt=/replication&wt=javabin&version=2&command=indexversion} status=0
> QTime=0
>[junit4] 2> 43004 INFO
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1)
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's generation: 12
>[junit4] 2> 43004 INFO
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1)
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Master's version:
> 1503514968639
>[junit4] 2> 43004 INFO
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1)
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's generation: 1
>[junit4] 2> 43004 INFO
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1)
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Slave's version: 0
>[junit4] 2> 43004 INFO
> (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:53170_solr
> x:cdcr-target_shard1_replica1 s:shard1 c:cdcr-target r:core_node1)
> [n:127.0.0.1:53170_solr c:cdcr-target s:shard1 r:core_node1
> x:cdcr-target_shard1_replica1] o.a.s.h.IndexFetcher Starting replication
> process
>[junit4] 2> 43041 INFO (qtp1525032019-71) [n:127.0.0.1:53178_solr
> c:cdcr-source s:shard1 r:core_node1 x:cdcr-source_shard1_replica1]
> o.a.s.h.ReplicationHandler Adding tlog files to list: [{size=4649,
> name=tlog.000.1576549701811961856}, {size=4770,
> name=tlog.001.1576549702515556352}, {size=4770,
> name=tlog.002.1576549702628802560}, {size=4770,
> name=tlog.003.1576549702720028672}, {size=4770,
> name=tlog.004.1576549702799720448}, {size=4770,
> name=tlog.005.1576549702894092288}, {size=4770,
> name=tlog.006.1576549703029358592}, {size=4770,
> name=tlog.007.1576549703126876160}, {size=4770,
> name=tlog.008.1576549703208665088}, {size=4770,
> name=tlog.009.1576549703295696896}
> {code}
> snippet2:
> {code}
> 17070[junit4] 2> 677606 INFO (qtp22544544-5725) []
> o.a.s.h.CdcrReplicatorManager Attempting to bootstrap target collection:
> cdcr-target, shard: shard1^M
> 17071[junit4] 2> 677608 INFO (qtp22544544-5725) []
> o.a.s.h.CdcrReplicatorManager Submitting bootstrap task to executor^M
> 17091[junit4] 2> 677627 INFO (qtp22544544-5724) []
> o.a.s.c.S.Request [cdcr-source_shard1_replica_n1] webapp=/solr
> path=/replication
> params={qt=/replication&wt=javabin&version=2&command=indexver
[JENKINS] Solr-reference-guide-master - Build # 2691 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-master/2691/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H19 (git-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision c6ed9f14ec214de8e2314ed77ced7b4e2a6de30b
(refs/remotes/origin/master)
Commit message: "SOLR-11446: Heavily edit the 'near real time searching' page
in the reference guide"
> git config core.sparsecheckout # timeout=10
> git checkout -f c6ed9f14ec214de8e2314ed77ced7b4e2a6de30b
> git rev-list 0b0ed2118277a5b22843faec259da5fefad2be53 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash
/tmp/jenkins9218248606602047392.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17 0311 3804 BB82 D39D C0E3
Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36 166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'
Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.
Upgrade Notes:
* No new notes to display.
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset wrappers
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 2 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
+ ant clean build-site build-pdf
Buildfile:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml
clean:
build-init:
[mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
[echo] Copying all non template files from src ...
[copy] Copying 371 files to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
[echo] Copy (w/prop replacement) any template files from src...
[copy] Copying 1 file to
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.
-ivy-fail-disallowed-ivy-version:
ivy-fail:
ivy-configure:
[ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 ::
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/lucene/top-level-ivy-settings.xml
resolve:
[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] ERRORS
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver null
[ivy:retrieve] unknown resolver
[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.7.0_80) - Build # 475 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/475/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseConcMarkSweepGC
4 tests failed.
FAILED: junit.framework.TestSuite.org.apache.solr.hadoop.MorphlineMapperTest
Error Message:
1 thread leaked from SUITE scope at org.apache.solr.hadoop.MorphlineMapperTest:
1) Thread[id=18, name=Thread-2, state=TIMED_WAITING,
group=TGRP-MorphlineMapperTest] at sun.misc.Unsafe.park(Native Method)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE
scope at org.apache.solr.hadoop.MorphlineMapperTest:
1) Thread[id=18, name=Thread-2, state=TIMED_WAITING,
group=TGRP-MorphlineMapperTest]
at sun.misc.Unsafe.park(Native Method)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
at __randomizedtesting.SeedInfo.seed([A6AC94CEF4D719D9]:0)
FAILED: junit.framework.TestSuite.org.apache.solr.hadoop.MorphlineMapperTest
Error Message:
There are still zombie threads that couldn't be terminated:1) Thread[id=18,
name=Thread-2, state=TIMED_WAITING, group=TGRP-MorphlineMapperTest] at
sun.misc.Unsafe.park(Native Method) at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie
threads that couldn't be terminated:
1) Thread[id=18, name=Thread-2, state=TIMED_WAITING,
group=TGRP-MorphlineMapperTest]
at sun.misc.Unsafe.park(Native Method)
at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
at org.apache.solr.hadoop.HeartBeater.run(HeartBeater.java:109)
at __randomizedtesting.SeedInfo.seed([A6AC94CEF4D719D9]:0)
FAILED: org.apache.solr.hadoop.MorphlineMapperTest.testMapper
Error Message:
Cannot instantiate Tika parser: org.apache.tika.parser.crypto.Pkcs7Parser near:
{ #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_A6AC94CEF4D719D9-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
201 # various java.text.SimpleDateFormat # xpath :
"/xhtml:html/xhtml:body/xhtml:div/descendant:node()" "uprefix" :
"ignored_", #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_A6AC94CEF4D719D9-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
158 "solrLocator" : { #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_A6AC94CEF4D719D9-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
158 "collection" : "collection1" }, #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_A6AC94CEF4D719D9-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
160 # captureAttr : true # default is false "capture" : [ #
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/contrib/solr-map-reduce/test/J0/temp/solr.hadoop.MorphlineMapperTest_A6AC94CEF4D719D9-001/tempDir-001/test-morphlines/solrCellDocumentTypes.conf:
163 # twitter feed schema "user_friends_count", #
/home/jenkins/workspace/Lucene-Solr-5.5-L
[jira] [Commented] (LUCENE-7736) Expose some IndexReader stats via DoubleValuesSources
[
https://issues.apache.org/jira/browse/LUCENE-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210111#comment-16210111
]
Adrien Grand commented on LUCENE-7736:
--
Thanks Alan. I think those new functions are going to be useful.
bq. One wrinkle here is that we can't compare closures, so
IndexReaderDoubleValuesSource only uses its description field for comparisons.
These are all private implementations, and there's a comment to that effect, so
I think this is OK.
I think this is incorrect as two instances that have been built on a different
reader will be considered equals even though they produce different values?
Let's pass things that are actually comparable to
{{IndexReaderDoubleValuesSource}} or just live with the fact that two instances
that do the same thing are considered unequal (which is ok imo as long as
a.equals(b) returns true if a == b)?
Should we use == rather than equals to know whether the source was rewritten? I
don't like one more than the other but since queries already use == I'd rather
like things to be consistent?
Did you remove the {{if (boost == 1f) return expl;}} from
{{FunctionScoreQuery}} on purpose? I know it is not necessary for correctness
but I still like the fact that it makes the explanation easier to read in the
default case that the boost is 1.
In {{TermFreqDoubleValuesSource}} could we just return an empty instance if the
term is not found instead of having to do a null check for every document?
In
{{lucene/queries/src/java/org/apache/lucene/queries/function/ValueSource.java}}
you seem to be assuming that rewriting only once is enough? Is it true?
> Expose some IndexReader stats via DoubleValuesSources
> -
>
> Key: LUCENE-7736
> URL: https://issues.apache.org/jira/browse/LUCENE-7736
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7736.patch, LUCENE-7736.patch, LUCENE-7736.patch,
> LUCENE-7736.patch
>
>
> We have a number of ValueSource implementations that expose IndexReader stats
> (numDocs, termFreq, etc). We should re-implement these as
> DoubleValuesSources, allowing them to be used in FunctionScoreQuery, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11509) Ref Guide: Upgrade notes for 7.1
Cassandra Targett created SOLR-11509: Summary: Ref Guide: Upgrade notes for 7.1 Key: SOLR-11509 URL: https://issues.apache.org/jira/browse/SOLR-11509 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Cassandra Targett Assignee: Cassandra Targett Fix For: 7.1 Upgrade notes for 7.1 and other miscellaneous TODOs for the 7.1 Ref Guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11464) Unused code in DistributedUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-11464:
Attachment: SOLR_11464_SOLR_11493_DistributedUrp.patch
I refactored this method further a little by reducing the indentation scope
(return early if zkEnabled), and limit the scope of the local {{List
nodes}} variable, and returning null where it would have been empty. In one
place used Collections.singletonList (callers never modify the result so we can
be immutable).
The tests passed with Gus's changes, and I'm running tests again now. If it
goes okay I'll commit it later.
(maybe one CHANGES.txt entry for 11464 and 11493 with comment "Minor
refactorings to DistributedUrp")
> Unused code in DistributedUpdateProcessor
> -
>
> Key: SOLR-11464
> URL: https://issues.apache.org/jira/browse/SOLR-11464
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (8.0)
>Reporter: Gus Heck
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-11464.patch,
> SOLR_11464_SOLR_11493_DistributedUrp.patch, unused.png
>
>
> While reading code I ran across a couple of suspicious unused
> values/variables. Thought I would raise this so that folks can consider if
> something was lost here, or if perhaps we can eliminate an unnecessary call
> to zookeeper and tidy things up a bit. Screenshot and patch to eliminate
> shortly...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6944) ReplicationFactorTest and HttpPartitionTest both fail with org.apache.http.NoHttpResponseException: The target server failed to respond
[ https://issues.apache.org/jira/browse/SOLR-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210047#comment-16210047 ] Erick Erickson edited comment on SOLR-6944 at 10/18/17 9:10 PM: I happen to be in this code for ReplicationFactorTest anyway and the BadApple annotation hasn't been removed in ReplicationFactorTest although it has been in HttpPartitionTest. Since I want to beef up these tests anyway (adding min_rf to deletes too) I propose that I: 1> remove the BadApple annotation 2> beast the heck out of it 3> add my tests If all that works, I'll check it all in and close this ticket along with SOLR-11438 (the issue I'm working on that lead me here in the first place). Objections? P.S. Assigning it to myself since I'm volunteering, [~markrmil...@gmail.com] feel free to take it back if you want of course. was (Author: erickerickson): I happen to be in this code for ReplicationFactorTest anyway and the BadApple annotation hasn't been removed in ReplicationFactorTest although it has been in HttpPartitionTest. Since I want to beef up these tests anyway (adding min_rf to deletes too) I propose that I: 1> remove the BadApple annotation 2> beast the heck out of it 3> add my tests If all that works, I'll check it all in and close this ticket along with SOLR-11438 (the issue I'm working on that lead me here in the first place). Objections? > ReplicationFactorTest and HttpPartitionTest both fail with > org.apache.http.NoHttpResponseException: The target server failed to respond > --- > > Key: SOLR-6944 > URL: https://issues.apache.org/jira/browse/SOLR-6944 > Project: Solr > Issue Type: Test >Reporter: Mark Miller >Assignee: Mark Miller > Attachments: SOLR-6944.patch > > > Our only recourse is to do a client side retry on such errors. I have some > retry code for this from SOLR-4509 that I will pull over here. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6944) ReplicationFactorTest and HttpPartitionTest both fail with org.apache.http.NoHttpResponseException: The target server failed to respond
[ https://issues.apache.org/jira/browse/SOLR-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-6944: Assignee: Erick Erickson (was: Mark Miller) > ReplicationFactorTest and HttpPartitionTest both fail with > org.apache.http.NoHttpResponseException: The target server failed to respond > --- > > Key: SOLR-6944 > URL: https://issues.apache.org/jira/browse/SOLR-6944 > Project: Solr > Issue Type: Test >Reporter: Mark Miller >Assignee: Erick Erickson > Attachments: SOLR-6944.patch > > > Our only recourse is to do a client side retry on such errors. I have some > retry code for this from SOLR-4509 that I will pull over here. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6944) ReplicationFactorTest and HttpPartitionTest both fail with org.apache.http.NoHttpResponseException: The target server failed to respond
[ https://issues.apache.org/jira/browse/SOLR-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210047#comment-16210047 ] Erick Erickson commented on SOLR-6944: -- I happen to be in this code for ReplicationFactorTest anyway and the BadApple annotation hasn't been removed in ReplicationFactorTest although it has been in HttpPartitionTest. Since I want to beef up these tests anyway (adding min_rf to deletes too) I propose that I: 1> remove the BadApple annotation 2> beast the heck out of it 3> add my tests If all that works, I'll check it all in and close this ticket along with SOLR-11438 (the issue I'm working on that lead me here in the first place). Objections? > ReplicationFactorTest and HttpPartitionTest both fail with > org.apache.http.NoHttpResponseException: The target server failed to respond > --- > > Key: SOLR-6944 > URL: https://issues.apache.org/jira/browse/SOLR-6944 > Project: Solr > Issue Type: Test >Reporter: Mark Miller >Assignee: Mark Miller > Attachments: SOLR-6944.patch > > > Our only recourse is to do a client side retry on such errors. I have some > retry code for this from SOLR-4509 that I will pull over here. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11446) Heavily edit the "near real time searching" page in the reference guide
[ https://issues.apache.org/jira/browse/SOLR-11446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210033#comment-16210033 ] Varun Thacker commented on SOLR-11446: -- Erick, The ref guide for 7.1 isn't out. So should we just backport it to that branch as well? > Heavily edit the "near real time searching" page in the reference guide > --- > > Key: SOLR-11446 > URL: https://issues.apache.org/jira/browse/SOLR-11446 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11446.patch > > > That page needs some focus, I'll attach a draft in a second (edited late last > night and not proofread yet). > Feedback welcome -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11446) Heavily edit the "near real time searching" page in the reference guide
[ https://issues.apache.org/jira/browse/SOLR-11446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210012#comment-16210012 ] ASF subversion and git services commented on SOLR-11446: Commit ec5825b4e75556813d50108ecdcab85cdc68d202 in lucene-solr's branch refs/heads/branch_7x from [~erickerickson] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ec5825b ] SOLR-11446: Heavily edit the 'near real time searching' page in the reference guide (cherry picked from commit c6ed9f1) > Heavily edit the "near real time searching" page in the reference guide > --- > > Key: SOLR-11446 > URL: https://issues.apache.org/jira/browse/SOLR-11446 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11446.patch > > > That page needs some focus, I'll attach a draft in a second (edited late last > night and not proofread yet). > Feedback welcome -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11446) Heavily edit the "near real time searching" page in the reference guide
[ https://issues.apache.org/jira/browse/SOLR-11446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-11446. --- Resolution: Fixed Fix Version/s: master (8.0) 7.2 > Heavily edit the "near real time searching" page in the reference guide > --- > > Key: SOLR-11446 > URL: https://issues.apache.org/jira/browse/SOLR-11446 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11446.patch > > > That page needs some focus, I'll attach a draft in a second (edited late last > night and not proofread yet). > Feedback welcome -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_144) - Build # 20692 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20692/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
3 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest
Error Message:
Error from server at http://127.0.0.1:33619/solr: create the collection time
out:180s
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:33619/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([605B21E493E245BF]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at
org.apache.solr.security.BasicAuthIntegrationTest.setupCluster(BasicAuthIntegrationTest.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
FAILED: org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration
Error Message:
Timed out waiting for replicas of collection to be 2 again null Live Nodes:
[127.0.0.1:36205_solr] Last available state:
DocCollection(testIntegration//collections/testIntegration/state.json/9)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"testIntegration_shard1_replica_n1",
"base_url":"https://127.0.0.1:36205/solr";,
"node_name":"127.0.0.1:36205_solr", "state":"active",
"type":"NRT", "leader":"true"}, "core_node4":{
"core":"testIntegration_shard1_replica_n2",
"base_url":"https://127.0.0.1:41473/solr";,
"node_name":"127.0.0
[jira] [Commented] (SOLR-11446) Heavily edit the "near real time searching" page in the reference guide
[ https://issues.apache.org/jira/browse/SOLR-11446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210007#comment-16210007 ] ASF subversion and git services commented on SOLR-11446: Commit c6ed9f14ec214de8e2314ed77ced7b4e2a6de30b in lucene-solr's branch refs/heads/master from [~erickerickson] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c6ed9f1 ] SOLR-11446: Heavily edit the 'near real time searching' page in the reference guide > Heavily edit the "near real time searching" page in the reference guide > --- > > Key: SOLR-11446 > URL: https://issues.apache.org/jira/browse/SOLR-11446 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-11446.patch > > > That page needs some focus, I'll attach a draft in a second (edited late last > night and not proofread yet). > Feedback welcome -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 869 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/869/
No tests ran.
Build Log:
[...truncated 28006 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
[copy] Copying 476 files to
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
[copy] Copying 215 files to
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
[smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
[smoker] NOTE: output encoding is UTF-8
[smoker]
[smoker] Load release URL
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
[smoker]
[smoker] Test Lucene...
[smoker] test basics...
[smoker] get KEYS
[smoker] 0.2 MB in 0.02 sec (14.8 MB/sec)
[smoker] check changes HTML...
[smoker] download lucene-8.0.0-src.tgz...
[smoker] 29.7 MB in 0.08 sec (361.6 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-8.0.0.tgz...
[smoker] 69.5 MB in 0.19 sec (360.8 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] download lucene-8.0.0.zip...
[smoker] 79.8 MB in 0.22 sec (366.7 MB/sec)
[smoker] verify md5/sha1 digests
[smoker] unpack lucene-8.0.0.tgz...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.8...
[smoker] got 6184 hits for query "lucene"
[smoker] checkindex with 1.8...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-8.0.0.zip...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.8...
[smoker] got 6184 hits for query "lucene"
[smoker] checkindex with 1.8...
[smoker] check Lucene's javadoc JAR
[smoker] unpack lucene-8.0.0-src.tgz...
[smoker] make sure no JARs/WARs in src dist...
[smoker] run "ant validate"
[smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
[smoker] test demo with 1.8...
[smoker] got 213 hits for query "lucene"
[smoker] checkindex with 1.8...
[smoker] generate javadocs w/ Java 8...
[smoker]
[smoker] Crawl/parse...
[smoker]
[smoker] Verify...
[smoker] confirm all releases have coverage in TestBackwardsCompatibility
[smoker] find all past Lucene releases...
[smoker] run TestBackwardsCompatibility..
[smoker] Releases that don't seem to be tested:
[smoker] 6.6.2
[smoker] Traceback (most recent call last):
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1484, in
[smoker] main()
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1428, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, ' '.join(c.test_args))
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1466, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
version, gitRevision, version, testArgs, baseURL)
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 622, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
gitRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 774, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
[smoker] File
"/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
line 1404, in confirmAllReleasesAreTestedForBackCompat
[smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:622:
exec returned: 1
Total time: 147 minutes 12 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 250 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/250/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory Error Message: replica never fully recovered Stack Trace: java.lang.AssertionError: replica never fully recovered at __randomizedtesting.SeedInfo.seed([8FDFD9A6029B189A:E2237D5BB8D3E79D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:303) at org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory(AutoscalingHistoryHandlerTest.java:255) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11851 lines...] [junit4] Suite: org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest [junit4]
[jira] [Updated] (SOLR-11506) Upgrade ref guide for Json Query DSL
[ https://issues.apache.org/jira/browse/SOLR-11506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-11506: - Attachment: SOLR-11506.patch I've attached a new patch after review where I've made several edits - mostly copy editing for proper placement of articles, capitalizing section titles and other words where necessary, monospacing parameter names, etc. The addition of the parameter mapping table is a good addition to the JSON Request API docs - it was the biggest thing I thought was missing. I think this is OK to go - I think it will need some more fleshing out in the future, but let's see what sorts of questions come up from users about it. > Upgrade ref guide for Json Query DSL > > > Key: SOLR-11506 > URL: https://issues.apache.org/jira/browse/SOLR-11506 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cao Manh Dat >Assignee: Cao Manh Dat > Attachments: SOLR-11506.patch, SOLR-11506.patch > > > Json Query DSL needs to be added into ref guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11252) Ref Guide: Add docs on JSON request api
[
https://issues.apache.org/jira/browse/SOLR-11252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-11252.
--
Resolution: Duplicate
> Ref Guide: Add docs on JSON request api
> ---
>
> Key: SOLR-11252
> URL: https://issues.apache.org/jira/browse/SOLR-11252
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, JSON Request API
>Reporter: Cassandra Targett
> Attachments: json-request-api.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on the JSON
> Request API ,but it never made its way into the published guides. During the
> conversion of the Ref Guide from Confluence, I made sure the page was
> exported and converted to {{.adoc}} format.
> Attaching that converted file here so someone could finish the conversion and
> check that it's accurate before adding to the Ref Guide - I'm not sure if
> there have been changes that should be documented, but perhaps there have
> been since the original page was quite old.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11252) Ref Guide: Add docs on JSON request api
[
https://issues.apache.org/jira/browse/SOLR-11252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209850#comment-16209850
]
Cassandra Targett commented on SOLR-11252:
--
SOLR-11506 adds these docs as part of the docs for the JSON Query DSL.
> Ref Guide: Add docs on JSON request api
> ---
>
> Key: SOLR-11252
> URL: https://issues.apache.org/jira/browse/SOLR-11252
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, JSON Request API
>Reporter: Cassandra Targett
> Attachments: json-request-api.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on the JSON
> Request API ,but it never made its way into the published guides. During the
> conversion of the Ref Guide from Confluence, I made sure the page was
> exported and converted to {{.adoc}} format.
> Attaching that converted file here so someone could finish the conversion and
> check that it's accurate before adding to the Ref Guide - I'm not sure if
> there have been changes that should be documented, but perhaps there have
> been since the original page was quite old.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 627 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/627/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.SystemLogListenerTest Error Message: Error from server at http://127.0.0.1:42055/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:42055/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([22B4B8D29E3F71EA]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.autoscaling.SystemLogListenerTest.setupCluster(SystemLogListenerTest.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.TriLevelCompositeIdRoutingTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:38877/_/zi Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:38877/_/zi at __randomizedtesting.SeedInfo.seed([22B4B8D29E3F71EA:AAE0870830C31C12]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
[jira] [Created] (SOLR-11508) core.properties should be stored $solr.data.home/$core.name
Marc Morissette created SOLR-11508:
--
Summary: core.properties should be stored
$solr.data.home/$core.name
Key: SOLR-11508
URL: https://issues.apache.org/jira/browse/SOLR-11508
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Marc Morissette
Since Solr 7, it is possible to store Solr cores in separate disk locations
using solr.data.home (see SOLR-6671). This is very useful where running Solr in
Docker where data must be stored in a directory which is independent from the
rest of the container.
Unfortunately, while core data is stored in
{{$\{solr.data.home}/$\{core.name}/index/...}}, core.properties is stored in
{{$\{solr.solr.home}/$\{core.name}/core.properties}}.
Reading SOLR-6671 comments, I think this was the expected behaviour but I don't
think it is the correct one.
In addition to being inelegant and counterintuitive, this has the drawback of
stripping a core of its metadata and breaking core discovery when a Solr
installation is redeployed, whether in Docker or not.
core.properties is mostly metadata and although it contains some configuration,
this configuration is specific to the core it accompanies. I believe it should
be stored in solr.data.home, with the rest of the data it describes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11508) core.properties should be stored $solr.data.home/$core.name
[
https://issues.apache.org/jira/browse/SOLR-11508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209794#comment-16209794
]
Marc Morissette commented on SOLR-11508:
Are there any objection before I begin work on a patch?
> core.properties should be stored $solr.data.home/$core.name
> ---
>
> Key: SOLR-11508
> URL: https://issues.apache.org/jira/browse/SOLR-11508
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Marc Morissette
>
> Since Solr 7, it is possible to store Solr cores in separate disk locations
> using solr.data.home (see SOLR-6671). This is very useful where running Solr
> in Docker where data must be stored in a directory which is independent from
> the rest of the container.
> Unfortunately, while core data is stored in
> {{$\{solr.data.home}/$\{core.name}/index/...}}, core.properties is stored in
> {{$\{solr.solr.home}/$\{core.name}/core.properties}}.
> Reading SOLR-6671 comments, I think this was the expected behaviour but I
> don't think it is the correct one.
> In addition to being inelegant and counterintuitive, this has the drawback of
> stripping a core of its metadata and breaking core discovery when a Solr
> installation is redeployed, whether in Docker or not.
> core.properties is mostly metadata and although it contains some
> configuration, this configuration is specific to the core it accompanies. I
> believe it should be stored in solr.data.home, with the rest of the data it
> describes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10401) Ranking
[ https://issues.apache.org/jira/browse/SOLR-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-10401: - Security: Public (was: Private (Security Issue)) > Ranking > --- > > Key: SOLR-10401 > URL: https://issues.apache.org/jira/browse/SOLR-10401 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: GENADIZ CARDONA > Labels: ranking, windows > Original Estimate: 372h > Remaining Estimate: 372h > > Spain Airports Ranking -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11184) Security vulnerability in delegation token functionality
[ https://issues.apache.org/jira/browse/SOLR-11184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-11184: - Security: Public (was: Private (Security Issue)) > Security vulnerability in delegation token functionality > > > Key: SOLR-11184 > URL: https://issues.apache.org/jira/browse/SOLR-11184 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: security, SolrCloud >Affects Versions: 6.2, 6.3, 6.4, 6.4.1, 6.4.2, 6.5, 6.5.1, 6.6 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 6.6.1, 7.0, master (8.0) > > Attachments: unit_test_fix.patch, zk_acl_fix.patch, > zk_acl_fix_6x.patch > > > -- Forwarded message -- > From: Hrishikesh Gadre > Date: Sat, Jul 22, 2017 at 3:59 AM > Subject: Apache Solr - security vulnerability (delegation token functionality) > To: secur...@apache.org > Hi, > We found a security vulnerability in the delegation token > functionality in Solr. This feature was added in Solr in 6.2 release > (SOLR-9200). > The delegation token functionality provided by Hadoop authentication > uses Apache curator framework to store the security related metadata. > Solr uses /security directory to store this information. > There are two issues with this functionality (when using > SecurityAwareZkACLProvider type of ACL provider e.g. > SaslZkACLProvider), > The ACLs for /security znode are configured as (‘world’,’anyone’) even > though the implementation of SecurityAwareZkACLProvider intends to > restrict access only for the solr super user. > The znodes under /security directory (e.g. /security/token) are > configured just like any other configuration file (i.e. modifiable by > solr admin and readable by world). SecurityAwareZkACLProvider on the > other hand intends to restrict access only for the solr super user. > The possible consequences of this vulnerability are severe. e.g. > (a) a malicious user can read the security tokens in Zookeeper and > gain access to the Solr cluster. > (b) a malicious user can delete the security related metadata in > Zookeeper and disrupt operations performed by authenticated users. > This is possible since the (‘world’,’anyone’) permission on /security > directory allows attacker to delete the child znodes under that path. > Please find the attached patch which includes a unit test and the fix. > Let me know if any additional information required from my side. > Thanks > Hrishikesh -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Release 5.5.5
Hi, The other problem is Morphlines. It's not compatible to latest TIKA! I later versions we removed the Morphlines plugin, but in 5.5 it won't work anymore. As far as I see, Solr 5.5 uses TIKA 1.7. I am not sure if this old version already have MATLAB support - does it contain jmatio.jar? If not, we can revert both updates: SOLR-8981 and SOLR-10335 Another alternative is to simply remove the MATLAB parser (delete jmatio and others - look at dependency tree). TIKA disables parsers with classloading errors automatically. I'd really keep the current version, otherwise we have to remove Morphlines. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Wednesday, October 18, 2017 8:01 PM > To: 'dev@lucene.apache.org' > Subject: RE: Release 5.5.5 > > There is still something fishy with 5.5 branch: > https://jenkins.thetaphi.de/job/Lucene-Solr-5.5- > Linux/lastCompletedBuild/testReport/org.apache.solr.morphlines.cell/SolrCe > llMorphlineTest/testSolrCellDocumentTypes2/ > > Was this caused by the TIKA updates? > > In total there are 6 test failures. > > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Steve Rowe [mailto:sar...@gmail.com] > > Sent: Tuesday, October 17, 2017 7:39 PM > > To: Lucene Dev > > Subject: Release 5.5.5 > > > > I think we should release a security-focused 5.5.5. I volunteer to be the > > release manager. > > > > I’ll make an RC later today after I backport issues. > > > > -- > > Steve > > www.lucidworks.com > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Release 5.5.5
There is still something fishy with 5.5 branch: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/lastCompletedBuild/testReport/org.apache.solr.morphlines.cell/SolrCellMorphlineTest/testSolrCellDocumentTypes2/ Was this caused by the TIKA updates? In total there are 6 test failures. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Steve Rowe [mailto:sar...@gmail.com] > Sent: Tuesday, October 17, 2017 7:39 PM > To: Lucene Dev > Subject: Release 5.5.5 > > I think we should release a security-focused 5.5.5. I volunteer to be the > release manager. > > I’ll make an RC later today after I backport issues. > > -- > Steve > www.lucidworks.com > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 186 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/186/ 5 tests failed. FAILED: org.apache.solr.cloud.AliasIntegrationTest.testErrorChecks Error Message: Error from server at https://127.0.0.1:45039/solr: deletealias the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:45039/solr: deletealias the collection time out:180s at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.AliasIntegrationTest.testErrorChecks(AliasIntegrationTest.java:201) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
[jira] [Commented] (SOLR-11144) Analytics Component Documentation
[
https://issues.apache.org/jira/browse/SOLR-11144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209702#comment-16209702
]
Cassandra Targett commented on SOLR-11144:
--
I've finally finished a rather thorough round of review & edits for these docs.
I changed a lot of stuff, so I created a branch {{jira/solr-11144}} and have
pushed that so you can pull the branch if you want - it's up to date with
master as of a few minutes ago.
I didn't keep a list of the stuff I changed as I went, so this list is from
memory - if you notice anything I changed to be incorrect, please let me know.
* I changed all of the usages of ⟹ to {{\=>}}. The character you used rendered
very small in both HTML and PDF. I could have left it as {{=>}} and asciidoctor
would have converted it to a nice icon that's larger than what you had used,
but this doesn't work in the PDF at all, so precommit doesn't allow it.
* A lot of your examples in the reference pages were in the form of {{"example
input" => "example output"}}, but the input/output sections should be
separately monospaced to avoid confusion about which is input and which is
output. I changed these so it would look like "{{example input}} => {{example
output}}" instead.
* I normalized a lot of uses of bold text, particularly in examples, and
changed a lot of capitalization of words to lower case.
* In {{analytics-reduction-functions.adoc}}, all of the examples were marked as
Labeled Lists (with the double colons at the end of the line), but unlike the
other pages of reference, there are no examples that follow. Since there was no
entry for the list, this broke the PDF. I removed all of these so they are just
plain examples on a single line for each reduction function.
* In {{analytics.adoc}}:
** I changed the presentation of many of the sections of parameters - we
generally do these as Labeled Lists, but you used nested unordered lists (i.e.,
bullet points) which were quite confusing. I _think_ I grokked the
relationships between all the parameters, but you should double-check those
because I had a hard time wrapping my head around it completely. As a related
note, parameters should also always be in monospace instead of bold - I think I
caught all of these, but may have missed one or two.
** I added some comments that we should address, particularly in the faceting &
grouping section. I could see this aspect of the component being used a lot,
and the parameters seem under-described to me.
** The section on Setup didn't cover adding the path to the .jar to the
directive in solrconfig.xml, so I added that. The Overview section was also
removed and replaced with it's sub-sections as main sections.
One thing I did not fix but needs to be fixed is a mismatch in some pages
between the page title and the page shortname - in order for PDF linking to
work properly, every {{page-shortname}} must match the title and must match the
filename (without the .adoc file extension), due to the way the PDF is built as
one massive file. If they don't match, the bookmark reference in the PDF won't
point to anything and users will jump halfway through a section (if the link
happens to work at all, sometimes it won't). This wasn't something you would
have known when you wrote this, but we need to fix it before we commit it. We
can either change the {{page-shortname}} & filenames on these pages or change
the page titles - which do you prefer? These are the pages with the mismatch:
* analytics-reduction-functions.adoc
* analytics-mapping-functions.adoc
* analytics-expression-sources.adoc
I think that's the bulk of what I changed but may have forgotten some major
things since I've been looking at this off & on for a few weeks between other
tasks - if you have any questions, please let me know.
> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Assignee: Cassandra Targett
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11493) Unnecessary creation of singlton lists in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-11493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reassigned SOLR-11493: --- Assignee: David Smiley > Unnecessary creation of singlton lists in DistributedUpdateProcessor > > > Key: SOLR-11493 > URL: https://issues.apache.org/jira/browse/SOLR-11493 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Gus Heck >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-11493.patch > > > I thought I'd found another bug because one of 4 variants didn't have a loop, > but then I noticed that the method in question was being fed a list, and the > very first thing it does is loop that list... so it seems there is no need to > loop the list, create and pass in a singleton list, and then have the method > loop that singleton list to process a single item... > Fixing this should save us a bit of object creation & therefore reduce GC > load. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11505) solr.cmd start of solr7.0.1 can't working in win7-64
[
https://issues.apache.org/jira/browse/SOLR-11505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209695#comment-16209695
]
Dawid Weiss commented on SOLR-11505:
Are you using {{powershell}} or {{cmd}}?
> solr.cmd start of solr7.0.1 can't working in win7-64
>
>
> Key: SOLR-11505
> URL: https://issues.apache.org/jira/browse/SOLR-11505
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.0.1
> Environment: windows 7
>Reporter: cloverliu
>Priority: Critical
>
> http://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip
> solr.cmd start of this file can't working in my win7-64bit.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11492) More Modern cloud dev script
[
https://issues.apache.org/jira/browse/SOLR-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209688#comment-16209688
]
David Smiley commented on SOLR-11492:
-
This looks cool.
I wanted to try it but failed because on Mac OS X, a BSD derivative, the "date"
executable doesn't support {{date -I}} so I replaced it with {{date
"+%Y\-%m\-%d"}}
> More Modern cloud dev script
>
>
> Key: SOLR-11492
> URL: https://issues.apache.org/jira/browse/SOLR-11492
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (8.0)
>Reporter: Gus Heck
>Priority: Minor
> Attachments: cloud.sh
>
>
> Most of the scripts in solr/cloud-dev do things like start using java -jar
> and other similarly ancient techniques. I recently decided I really didn't
> like that it was a pain to setup a cloud to test a patch/feature and that
> often one winds up needing to blow away existing testing so working on more
> than one thing at a time is irritating... so here's a script I wrote, if
> folks like it I'd be happy for it to be included in solr/cloud-dev
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2124 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2124/ 7 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:34863/wu/lx/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:34863/wu/lx/collection1 at __randomizedtesting.SeedInfo.seed([BF3136144E12C0CD:376509CEE0EEAD35]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484) at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1583) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:213) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.ca
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 253 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/253/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC --illegal-access=deny
2 tests failed.
FAILED: org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration
Error Message:
Timed out waiting for replicas of collection to be 2 again null Live Nodes:
[127.0.0.1:62201_solr] Last available state:
DocCollection(testIntegration//collections/testIntegration/state.json/7)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node3":{ "core":"testIntegration_shard1_replica_n1",
"base_url":"https://127.0.0.1:62200/solr";,
"node_name":"127.0.0.1:62200_solr", "state":"down",
"type":"NRT"}, "core_node4":{
"core":"testIntegration_shard1_replica_n2",
"base_url":"https://127.0.0.1:62201/solr";,
"node_name":"127.0.0.1:62201_solr", "state":"active",
"type":"NRT", "leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"2",
"tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError: Timed out waiting for replicas of collection to be 2
again
null
Live Nodes: [127.0.0.1:62201_solr]
Last available state:
DocCollection(testIntegration//collections/testIntegration/state.json/7)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node3":{
"core":"testIntegration_shard1_replica_n1",
"base_url":"https://127.0.0.1:62200/solr";,
"node_name":"127.0.0.1:62200_solr",
"state":"down",
"type":"NRT"},
"core_node4":{
"core":"testIntegration_shard1_replica_n2",
"base_url":"https://127.0.0.1:62201/solr";,
"node_name":"127.0.0.1:62201_solr",
"state":"active",
"type":"NRT",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([4E9F09431F087854:FEFE076F3A37D971]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at
org.apache.solr.cloud.autoscaling.ExecutePlanActionTest.testIntegration(ExecutePlanActionTest.java:209)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36
[JENKINS] Lucene-Solr-6.6-Linux (32bit/jdk1.8.0_144) - Build # 176 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/176/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC
1 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:36713","node_name":"127.0.0.1:36713_","state":"active","leader":"true"}];
clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/27)={
"replicationFactor":"3", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node1":{ "state":"down",
"base_url":"http://127.0.0.1:44057";,
"core":"c8n_1x3_lf_shard1_replica1", "node_name":"127.0.0.1:44057_"},
"core_node2":{ "core":"c8n_1x3_lf_shard1_replica3",
"base_url":"http://127.0.0.1:44247";, "node_name":"127.0.0.1:44247_",
"state":"down"}, "core_node3":{
"core":"c8n_1x3_lf_shard1_replica2",
"base_url":"http://127.0.0.1:36713";, "node_name":"127.0.0.1:36713_",
"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:36713","node_name":"127.0.0.1:36713_","state":"active","leader":"true"}];
clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/27)={
"replicationFactor":"3",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node1":{
"state":"down",
"base_url":"http://127.0.0.1:44057";,
"core":"c8n_1x3_lf_shard1_replica1",
"node_name":"127.0.0.1:44057_"},
"core_node2":{
"core":"c8n_1x3_lf_shard1_replica3",
"base_url":"http://127.0.0.1:44247";,
"node_name":"127.0.0.1:44247_",
"state":"down"},
"core_node3":{
"core":"c8n_1x3_lf_shard1_replica2",
"base_url":"http://127.0.0.1:36713";,
"node_name":"127.0.0.1:36713_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false"}
at
__randomizedtesting.SeedInfo.seed([52A3B40E92477BDA:DAF78BD43CBB1622]: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:168)
at
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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)
a
[jira] [Commented] (SOLR-11459) AddUpdateCommand#prevVersion is not cleared which may lead to problem for in-place updates of non existed documents
[
https://issues.apache.org/jira/browse/SOLR-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209598#comment-16209598
]
Ishan Chattopadhyaya commented on SOLR-11459:
-
Hi Andrey,
I'm currently on a vacation and shall take a look at this on Friday.
On a cursory glance, it seems what you're recommending makes sense. I'll have
to be more thorough in order to be sure.
There are TestInPlaceUpdatesStandalone and TestInPlaceUpdatesDistrib tests.
> AddUpdateCommand#prevVersion is not cleared which may lead to problem for
> in-place updates of non existed documents
> ---
>
> Key: SOLR-11459
> URL: https://issues.apache.org/jira/browse/SOLR-11459
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
>
> I have a 1_shard / *m*_replicas SolrCloud cluster with Solr 6.6.0 and run
> batches of 5 - 10k in-place updates from time to time.
> Once I noticed that job "hangs" - it started and couldn't finish for a a
> while.
> Logs were full of messages like:
> {code} Missing update, on which current in-place update depends on, hasn't
> arrived. id=__, looking for version=___, last found version=0" {code}
> {code}
> Tried to fetch document ___ from the leader, but the leader says document has
> been deleted. Deleting the document here and skipping this update: Last found
> version: 0, was looking for: ___",24,0,"but the leader says document has been
> deleted. Deleting the document here and skipping this update: Last found
> version: 0
> {code}
> Further analysis shows that:
> * There are 100-500 updates for non-existed documents among other updates
> (something that I have to deal with)
> * Leader receives bunch of updates and executes this updates one by one.
> {{JavabinLoader}} which is used by processing documents reuses same instance
> of {{AddUpdateCommand}} for every update and just [clearing its state at the
> end|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99].
> Field [AddUpdateCommand#prevVersion|
> https://github.com/apache/lucene-solr/blob/6396cb759f8c799f381b0730636fa412761030ce/solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java#L76]
> is not cleared.
> * In case of update is in-place update, but specified document does not
> exist, this update is processed as a regular atomic update (i.e. new doc is
> created), but {{prevVersion}} is used as a {{distrib.inplace.prevversion}}
> parameter in sequential calls to every slave in DistributedUpdateProcessor.
> {{prevVersion}} wasn't cleared, so it may contain version from previous
> processed update.
> * Slaves checks it's own version of documents which is 0 (cause doc does not
> exist), slave thinks that some updates were missed and spends 5 seconds in
> [DistributedUpdateProcessor#waitForDependentUpdates|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99]
> waiting for missed updates (no luck) and also tries to get "correct" version
> from leader (no luck as well)
> * So update for non existed document costs *m* * 5 sec each
> I workarounded this by explicit check of doc existence, but it probably
> should be fixed.
> Obviously first guess is that prevVersion should be cleared in
> {{AddUpdateCommand#clear}}, but have no clue how to test it.
> {code}
> +++ solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java
> (revision )
> @@ -78,6 +78,7 @@
> updateTerm = null;
> isLastDocInBatch = false;
> version = 0;
> + prevVersion = -1;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7995) 'ant stage-maven-artifacts' should work from the top-level project directory, and should provide a better error message when its 'maven.dist.dir' param points to a non-e
[ https://issues.apache.org/jira/browse/LUCENE-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated LUCENE-7995: --- Fix Version/s: 5.5.5 > 'ant stage-maven-artifacts' should work from the top-level project directory, > and should provide a better error message when its 'maven.dist.dir' param > points to a non-existent directory > -- > > Key: LUCENE-7995 > URL: https://issues.apache.org/jira/browse/LUCENE-7995 > Project: Lucene - Core > Issue Type: Bug >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: 5.5.5, 6.7, master (8.0), 7.0.2, 7.2, 6.6.3, 7.1.1 > > Attachments: LUCENE-7995.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11389) call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]
[
https://issues.apache.org/jira/browse/SOLR-11389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209569#comment-16209569
]
Christine Poerschke commented on SOLR-11389:
Changes committed to master branch; post commit input still welcome as usual.
Will let the change settle in on master branch for a few days before
cherry-picking to branch_7x branch.
> call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]
> --
>
> Key: SOLR-11389
> URL: https://issues.apache.org/jira/browse/SOLR-11389
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11389.patch, SOLR-11389.patch
>
>
> Currently
> [SolrMetricManager.loadReporter|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.0.0/solr/core/src/java/org/apache/solr/metrics/SolrMetricManager.java#L823-L844]
> does four things:
> * creates a new {{SolrMetricReporter}} instance (object)
> * calls {{reporter.init(pluginInfo);}} on the object
> * calls {{registerReporter(registry, pluginInfo.name, tag, reporter);}} for
> the object
> * {{return reporter;}} returns the object
> For the returned object the {{SolrMetricManager.loadShardReporters}} and
> {{SolrMetricManager.loadClusterReporters}} callers of
> SolrMetricManager.loadReporter then call the
> {{((SolrShardReporter)reporter).setCore(core);}} or
> {{((SolrClusterReporter)reporter).setCoreContainer(cc);}} method. This means
> that {{registerReporter}} happened before the SolrShardReporter and
> SolrClusterReporter objects were fully set up. _(I have not yet fully
> investigated if this might be unintentional-and-not-required or
> intentional-and-required.)_
> The changes proposed in this ticket can be summarised as follows:
> * SolrMetricReporter.java
> {code}
> - public SolrMetricReporter loadReporter(...) throws Exception {
> + public void loadReporter(...) throws Exception {
> ...
> try {
> - reporter.init(pluginInfo);
> + if (reporter instanceof SolrShardReporter) {
> +((SolrShardReporter)reporter).init(pluginInfo, solrCore);
> + } else if (reporter instanceof SolrClusterReporter) {
> +((SolrClusterReporter)reporter).init(pluginInfo, coreContainer);
> + } else {
> +reporter.init(pluginInfo);
> + }
> } catch (IllegalStateException e) {
>throw new IllegalArgumentException("reporter init failed: " +
> pluginInfo, e);
> }
> registerReporter(registry, pluginInfo.name, tag, reporter);
> -return reporter;
>}
> {code}
> * SolrShardReporter.java
> {code}
> + @Override
> + public void init(PluginInfo pluginInfo) {
> +throw new
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
> is not supported, use init(PluginInfo,SolrCore) instead.");
> + }
> - public void setCore(SolrCore core) {
> + public void init(PluginInfo pluginInfo, SolrCore core) {
> +super.init(pluginInfo);
> ...
>}
> {code}
> * SolrClusterReporter.java
> {code}
> + @Override
> + public void init(PluginInfo pluginInfo) {
> +throw new
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
> is not supported, use init(PluginInfo,CoreContainer) instead.");
> + }
> - public void setCoreContainer(CoreContainer cc) {
> + public void init(PluginInfo pluginInfo, CoreContainer cc) {
> +super.init(pluginInfo);
> ...
>}
> {code}
> Context and motivation for the proposed changes is to support (in SOLR-11291)
> the factoring out of an abstract SolrCoreReporter class, allowing folks to
> create new reporters that 'know' the SolrCore they are reporting on.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11389) call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]
[
https://issues.apache.org/jira/browse/SOLR-11389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209567#comment-16209567
]
ASF subversion and git services commented on SOLR-11389:
Commit 0b0ed2118277a5b22843faec259da5fefad2be53 in lucene-solr's branch
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0b0ed21 ]
SOLR-11389: For Solr(Shard|Cluster)Reporter instances the
SolrMetricManager.registerReporter method is now called after the SolrCore or
CoreContainer has been set for the instance.
> call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]
> --
>
> Key: SOLR-11389
> URL: https://issues.apache.org/jira/browse/SOLR-11389
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11389.patch, SOLR-11389.patch
>
>
> Currently
> [SolrMetricManager.loadReporter|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.0.0/solr/core/src/java/org/apache/solr/metrics/SolrMetricManager.java#L823-L844]
> does four things:
> * creates a new {{SolrMetricReporter}} instance (object)
> * calls {{reporter.init(pluginInfo);}} on the object
> * calls {{registerReporter(registry, pluginInfo.name, tag, reporter);}} for
> the object
> * {{return reporter;}} returns the object
> For the returned object the {{SolrMetricManager.loadShardReporters}} and
> {{SolrMetricManager.loadClusterReporters}} callers of
> SolrMetricManager.loadReporter then call the
> {{((SolrShardReporter)reporter).setCore(core);}} or
> {{((SolrClusterReporter)reporter).setCoreContainer(cc);}} method. This means
> that {{registerReporter}} happened before the SolrShardReporter and
> SolrClusterReporter objects were fully set up. _(I have not yet fully
> investigated if this might be unintentional-and-not-required or
> intentional-and-required.)_
> The changes proposed in this ticket can be summarised as follows:
> * SolrMetricReporter.java
> {code}
> - public SolrMetricReporter loadReporter(...) throws Exception {
> + public void loadReporter(...) throws Exception {
> ...
> try {
> - reporter.init(pluginInfo);
> + if (reporter instanceof SolrShardReporter) {
> +((SolrShardReporter)reporter).init(pluginInfo, solrCore);
> + } else if (reporter instanceof SolrClusterReporter) {
> +((SolrClusterReporter)reporter).init(pluginInfo, coreContainer);
> + } else {
> +reporter.init(pluginInfo);
> + }
> } catch (IllegalStateException e) {
>throw new IllegalArgumentException("reporter init failed: " +
> pluginInfo, e);
> }
> registerReporter(registry, pluginInfo.name, tag, reporter);
> -return reporter;
>}
> {code}
> * SolrShardReporter.java
> {code}
> + @Override
> + public void init(PluginInfo pluginInfo) {
> +throw new
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
> is not supported, use init(PluginInfo,SolrCore) instead.");
> + }
> - public void setCore(SolrCore core) {
> + public void init(PluginInfo pluginInfo, SolrCore core) {
> +super.init(pluginInfo);
> ...
>}
> {code}
> * SolrClusterReporter.java
> {code}
> + @Override
> + public void init(PluginInfo pluginInfo) {
> +throw new
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
> is not supported, use init(PluginInfo,CoreContainer) instead.");
> + }
> - public void setCoreContainer(CoreContainer cc) {
> + public void init(PluginInfo pluginInfo, CoreContainer cc) {
> +super.init(pluginInfo);
> ...
>}
> {code}
> Context and motivation for the proposed changes is to support (in SOLR-11291)
> the factoring out of an abstract SolrCoreReporter class, allowing folks to
> create new reporters that 'know' the SolrCore they are reporting on.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7995) 'ant stage-maven-artifacts' should work from the top-level project directory, and should provide a better error message when its 'maven.dist.dir' param points to a non
[ https://issues.apache.org/jira/browse/LUCENE-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209561#comment-16209561 ] ASF subversion and git services commented on LUCENE-7995: - Commit 7c38bced453d915021f844174af4a90c77641329 in lucene-solr's branch refs/heads/branch_5_5 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c38bce ] LUCENE-7995: 'ant stage-maven-artifacts' should work from the top-level project directory, and should provide a better error message when its 'maven.dist.dir' param points to a non-existent directory > 'ant stage-maven-artifacts' should work from the top-level project directory, > and should provide a better error message when its 'maven.dist.dir' param > points to a non-existent directory > -- > > Key: LUCENE-7995 > URL: https://issues.apache.org/jira/browse/LUCENE-7995 > Project: Lucene - Core > Issue Type: Bug >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: 6.7, master (8.0), 7.0.2, 7.2, 6.6.3, 7.1.1 > > Attachments: LUCENE-7995.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11072) Implement trigger for searchRate event type
[
https://issues.apache.org/jira/browse/SOLR-11072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209558#comment-16209558
]
Andrzej Bialecki commented on SOLR-11072:
--
This was actually reverted from {{feature/autoscaling}} so it never made it
into 7.1, because we discovered that it depends on SOLR-11320 and SOLR-11448.
> Implement trigger for searchRate event type
> ---
>
> Key: SOLR-11072
> URL: https://issues.apache.org/jira/browse/SOLR-11072
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11072.patch, SOLR-11072.patch
>
>
> Implement support for triggers based on searchRate event type. This can be
> used to add replicas when the rate of queries increases over a threshold and
> remains high for a configurable period of time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11072) Implement trigger for searchRate event type
[ https://issues.apache.org/jira/browse/SOLR-11072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-11072: - Fix Version/s: (was: 7.1) master (8.0) 7.2 > Implement trigger for searchRate event type > --- > > Key: SOLR-11072 > URL: https://issues.apache.org/jira/browse/SOLR-11072 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11072.patch, SOLR-11072.patch > > > Implement support for triggers based on searchRate event type. This can be > used to add replicas when the rate of queries increases over a threshold and > remains high for a configurable period of time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11459) AddUpdateCommand#prevVersion is not cleared which may lead to problem for in-place updates of non existed documents
[
https://issues.apache.org/jira/browse/SOLR-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya reassigned SOLR-11459:
---
Assignee: Ishan Chattopadhyaya
> AddUpdateCommand#prevVersion is not cleared which may lead to problem for
> in-place updates of non existed documents
> ---
>
> Key: SOLR-11459
> URL: https://issues.apache.org/jira/browse/SOLR-11459
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
>
> I have a 1_shard / *m*_replicas SolrCloud cluster with Solr 6.6.0 and run
> batches of 5 - 10k in-place updates from time to time.
> Once I noticed that job "hangs" - it started and couldn't finish for a a
> while.
> Logs were full of messages like:
> {code} Missing update, on which current in-place update depends on, hasn't
> arrived. id=__, looking for version=___, last found version=0" {code}
> {code}
> Tried to fetch document ___ from the leader, but the leader says document has
> been deleted. Deleting the document here and skipping this update: Last found
> version: 0, was looking for: ___",24,0,"but the leader says document has been
> deleted. Deleting the document here and skipping this update: Last found
> version: 0
> {code}
> Further analysis shows that:
> * There are 100-500 updates for non-existed documents among other updates
> (something that I have to deal with)
> * Leader receives bunch of updates and executes this updates one by one.
> {{JavabinLoader}} which is used by processing documents reuses same instance
> of {{AddUpdateCommand}} for every update and just [clearing its state at the
> end|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99].
> Field [AddUpdateCommand#prevVersion|
> https://github.com/apache/lucene-solr/blob/6396cb759f8c799f381b0730636fa412761030ce/solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java#L76]
> is not cleared.
> * In case of update is in-place update, but specified document does not
> exist, this update is processed as a regular atomic update (i.e. new doc is
> created), but {{prevVersion}} is used as a {{distrib.inplace.prevversion}}
> parameter in sequential calls to every slave in DistributedUpdateProcessor.
> {{prevVersion}} wasn't cleared, so it may contain version from previous
> processed update.
> * Slaves checks it's own version of documents which is 0 (cause doc does not
> exist), slave thinks that some updates were missed and spends 5 seconds in
> [DistributedUpdateProcessor#waitForDependentUpdates|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99]
> waiting for missed updates (no luck) and also tries to get "correct" version
> from leader (no luck as well)
> * So update for non existed document costs *m* * 5 sec each
> I workarounded this by explicit check of doc existence, but it probably
> should be fixed.
> Obviously first guess is that prevVersion should be cleared in
> {{AddUpdateCommand#clear}}, but have no clue how to test it.
> {code}
> +++ solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java
> (revision )
> @@ -78,6 +78,7 @@
> updateTerm = null;
> isLastDocInBatch = false;
> version = 0;
> + prevVersion = -1;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11490) Add @since javadoc tags to the interesting Solr/Lucene classes
[ https://issues.apache.org/jira/browse/SOLR-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209519#comment-16209519 ] Alexandre Rafalovitch commented on SOLR-11490: -- Sure. Let's correct whatever is wrong. Maybe this patch is correct for most of entries but is wrong for some specific ones. Then, we can figure out the specific set and ensure it is treated right for both this and future additions. So, let's take ArabicStemFilterFactory as an example you probably meant to use (ArabicTokenizer does not seem to exist). I see it in the release 1.4: https://github.com/apache/lucene-solr/blob/releases/solr/1.4.0/src/java/org/apache/solr/analysis/ArabicStemFilterFactory.java Now, that's release predating Lucene and Solr merge (in 3.1), so perhaps this is the part we need to discuss to make it clearer? I also see that it was moved to Lucene packages from Solr packages: https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/ar/ArabicStemFilterFactory.java This happened with LUCENE-2510 for Lucene/Solr 4. But that's the package change and the functionality did not change. So, the user that needs to work with Arabic text still could. I am not sure what happened in Lucene 2.9.0. I can see LUCENE-1460 which seems relevant, but the functionality in question seems to have been present both before and after. What am I missing? > Add @since javadoc tags to the interesting Solr/Lucene classes > -- > > Key: SOLR-11490 > URL: https://issues.apache.org/jira/browse/SOLR-11490 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > > As per the discussion on the dev list, it may be useful to add Javadoc since > tags to significant (or even all) Java files. > For user-facing files (such as analyzers, URPs, stream evaluators, etc) it > would be useful when trying to identifying whether a particular class only > comes later than user's particular version. > For other classes, it may be useful for historical reasons. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11389) call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]
[
https://issues.apache.org/jira/browse/SOLR-11389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-11389:
---
Attachment: SOLR-11389.patch
Attaching rebased patch (there was one trivial import related conflict).
> call registerReporter after Solr(Shard|Cluster)Reporter.setCore[Container]
> --
>
> Key: SOLR-11389
> URL: https://issues.apache.org/jira/browse/SOLR-11389
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11389.patch, SOLR-11389.patch
>
>
> Currently
> [SolrMetricManager.loadReporter|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.0.0/solr/core/src/java/org/apache/solr/metrics/SolrMetricManager.java#L823-L844]
> does four things:
> * creates a new {{SolrMetricReporter}} instance (object)
> * calls {{reporter.init(pluginInfo);}} on the object
> * calls {{registerReporter(registry, pluginInfo.name, tag, reporter);}} for
> the object
> * {{return reporter;}} returns the object
> For the returned object the {{SolrMetricManager.loadShardReporters}} and
> {{SolrMetricManager.loadClusterReporters}} callers of
> SolrMetricManager.loadReporter then call the
> {{((SolrShardReporter)reporter).setCore(core);}} or
> {{((SolrClusterReporter)reporter).setCoreContainer(cc);}} method. This means
> that {{registerReporter}} happened before the SolrShardReporter and
> SolrClusterReporter objects were fully set up. _(I have not yet fully
> investigated if this might be unintentional-and-not-required or
> intentional-and-required.)_
> The changes proposed in this ticket can be summarised as follows:
> * SolrMetricReporter.java
> {code}
> - public SolrMetricReporter loadReporter(...) throws Exception {
> + public void loadReporter(...) throws Exception {
> ...
> try {
> - reporter.init(pluginInfo);
> + if (reporter instanceof SolrShardReporter) {
> +((SolrShardReporter)reporter).init(pluginInfo, solrCore);
> + } else if (reporter instanceof SolrClusterReporter) {
> +((SolrClusterReporter)reporter).init(pluginInfo, coreContainer);
> + } else {
> +reporter.init(pluginInfo);
> + }
> } catch (IllegalStateException e) {
>throw new IllegalArgumentException("reporter init failed: " +
> pluginInfo, e);
> }
> registerReporter(registry, pluginInfo.name, tag, reporter);
> -return reporter;
>}
> {code}
> * SolrShardReporter.java
> {code}
> + @Override
> + public void init(PluginInfo pluginInfo) {
> +throw new
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
> is not supported, use init(PluginInfo,SolrCore) instead.");
> + }
> - public void setCore(SolrCore core) {
> + public void init(PluginInfo pluginInfo, SolrCore core) {
> +super.init(pluginInfo);
> ...
>}
> {code}
> * SolrClusterReporter.java
> {code}
> + @Override
> + public void init(PluginInfo pluginInfo) {
> +throw new
> UnsupportedOperationException(getClass().getCanonicalName()+".init(PluginInfo)
> is not supported, use init(PluginInfo,CoreContainer) instead.");
> + }
> - public void setCoreContainer(CoreContainer cc) {
> + public void init(PluginInfo pluginInfo, CoreContainer cc) {
> +super.init(pluginInfo);
> ...
>}
> {code}
> Context and motivation for the proposed changes is to support (in SOLR-11291)
> the factoring out of an abstract SolrCoreReporter class, allowing folks to
> create new reporters that 'know' the SolrCore they are reporting on.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.8.0_144) - Build # 474 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/474/ Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC 6 tests failed. FAILED: org.apache.solr.cloud.PeerSyncReplicationTest.test Error Message: expected:<152> but was:<146> Stack Trace: java.lang.AssertionError: expected:<152> but was:<146> at __randomizedtesting.SeedInfo.seed([DC5DCBCF3BA3B54E:5409F415955FD8B6]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:278) at org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:242) at org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:125) 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:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) 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(TestRuleIgno
[jira] [Commented] (SOLR-11459) AddUpdateCommand#prevVersion is not cleared which may lead to problem for in-place updates of non existed documents
[
https://issues.apache.org/jira/browse/SOLR-11459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209491#comment-16209491
]
Andrey Kudryavtsev commented on SOLR-11459:
---
[~ichattopadhyaya], any thoughts about this?
> AddUpdateCommand#prevVersion is not cleared which may lead to problem for
> in-place updates of non existed documents
> ---
>
> Key: SOLR-11459
> URL: https://issues.apache.org/jira/browse/SOLR-11459
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Priority: Minor
>
> I have a 1_shard / *m*_replicas SolrCloud cluster with Solr 6.6.0 and run
> batches of 5 - 10k in-place updates from time to time.
> Once I noticed that job "hangs" - it started and couldn't finish for a a
> while.
> Logs were full of messages like:
> {code} Missing update, on which current in-place update depends on, hasn't
> arrived. id=__, looking for version=___, last found version=0" {code}
> {code}
> Tried to fetch document ___ from the leader, but the leader says document has
> been deleted. Deleting the document here and skipping this update: Last found
> version: 0, was looking for: ___",24,0,"but the leader says document has been
> deleted. Deleting the document here and skipping this update: Last found
> version: 0
> {code}
> Further analysis shows that:
> * There are 100-500 updates for non-existed documents among other updates
> (something that I have to deal with)
> * Leader receives bunch of updates and executes this updates one by one.
> {{JavabinLoader}} which is used by processing documents reuses same instance
> of {{AddUpdateCommand}} for every update and just [clearing its state at the
> end|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99].
> Field [AddUpdateCommand#prevVersion|
> https://github.com/apache/lucene-solr/blob/6396cb759f8c799f381b0730636fa412761030ce/solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java#L76]
> is not cleared.
> * In case of update is in-place update, but specified document does not
> exist, this update is processed as a regular atomic update (i.e. new doc is
> created), but {{prevVersion}} is used as a {{distrib.inplace.prevversion}}
> parameter in sequential calls to every slave in DistributedUpdateProcessor.
> {{prevVersion}} wasn't cleared, so it may contain version from previous
> processed update.
> * Slaves checks it's own version of documents which is 0 (cause doc does not
> exist), slave thinks that some updates were missed and spends 5 seconds in
> [DistributedUpdateProcessor#waitForDependentUpdates|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java#L99]
> waiting for missed updates (no luck) and also tries to get "correct" version
> from leader (no luck as well)
> * So update for non existed document costs *m* * 5 sec each
> I workarounded this by explicit check of doc existence, but it probably
> should be fixed.
> Obviously first guess is that prevVersion should be cleared in
> {{AddUpdateCommand#clear}}, but have no clue how to test it.
> {code}
> +++ solr/core/src/java/org/apache/solr/update/AddUpdateCommand.java
> (revision )
> @@ -78,6 +78,7 @@
> updateTerm = null;
> isLastDocInBatch = false;
> version = 0;
> + prevVersion = -1;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
