[JENKINS] Lucene-Solr-Tests-master - Build # 2178 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2178/ 4 tests failed. FAILED: org.apache.solr.cloud.AliasIntegrationTest.test Error Message: Unexpected exception type, expected SolrException but got org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:34312/solr/testalias, https://127.0.0.1:40009/solr/testalias] Stack Trace: junit.framework.AssertionFailedError: Unexpected exception type, expected SolrException but got org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:34312/solr/testalias, https://127.0.0.1:40009/solr/testalias] at __randomizedtesting.SeedInfo.seed([62A2C6158E8B2A0:8E7E13BBF614DF58]:0) at org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2660) at org.apache.solr.cloud.AliasIntegrationTest.test(AliasIntegrationTest.java:252) 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)
[jira] [Updated] (SOLR-11655) SolrCloud should Support encrypted zookeeper ACL Digest details
[ https://issues.apache.org/jira/browse/SOLR-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parvez Kazi updated SOLR-11655: --- Description: In SolrCloud, to connect to zookeeper, we need to provide zookeeper credentials and acls in below format : (plain text) SOLR_ZK_CREDS_AND_ACLS="-DzkACLProvider=org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider \ -DzkCredentialsProvider=org.apache.solr.common.cloud.VMParamsSingleSetCredentialsDigestZkCredentialsProvider \ -DzkDigestUsername=admin -DzkDigestPassword=admin123 \ -DzkDigestReadonlyUsername=admin -DzkDigestReadonlyPassword=admin123" We want to have these credentials in encrypted format. Do we have this supported and if yes how to implement? If not, is this planned in future releases? Please update on this,. SOLR Version : solr-6.5.1 ZK Version zookeeper-3.4.8 was: In SolrCloud, to connect to zookeeper, we need to provide zookeeper credentials and acls in below format : (plain text) SOLR_ZK_CREDS_AND_ACLS="-DzkACLProvider=org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider \ -DzkCredentialsProvider=org.apache.solr.common.cloud.VMParamsSingleSetCredentialsDigestZkCredentialsProvider \ -DzkDigestUsername=admin -DzkDigestPassword=admin123 \ -DzkDigestReadonlyUsername=admin -DzkDigestReadonlyPassword=admin123" We want to have these credentials in encrypted format. Do we have this supported and if yes how to implement? If not, is this planned in future releases? Please update on this,. > SolrCloud should Support encrypted zookeeper ACL Digest details > --- > > Key: SOLR-11655 > URL: https://issues.apache.org/jira/browse/SOLR-11655 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Parvez Kazi > > In SolrCloud, to connect to zookeeper, we need to provide zookeeper > credentials and acls in below format : (plain text) > SOLR_ZK_CREDS_AND_ACLS="-DzkACLProvider=org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider > \ > -DzkCredentialsProvider=org.apache.solr.common.cloud.VMParamsSingleSetCredentialsDigestZkCredentialsProvider > \ > -DzkDigestUsername=admin -DzkDigestPassword=admin123 \ > -DzkDigestReadonlyUsername=admin -DzkDigestReadonlyPassword=admin123" > We want to have these credentials in encrypted format. > Do we have this supported and if yes how to implement? > If not, is this planned in future releases? > Please update on this,. > SOLR Version : > solr-6.5.1 > ZK Version > zookeeper-3.4.8 -- 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 # 889 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/889/ No tests ran. Build Log: [...truncated 28007 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.02 sec (11.1 MB/sec) [smoker] check changes HTML... [smoker] download lucene-8.0.0-src.tgz... [smoker] 29.8 MB in 0.07 sec (401.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.tgz... [smoker] 70.9 MB in 0.14 sec (512.5 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.zip... [smoker] 81.3 MB in 0.08 sec (1077.3 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 6194 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 6194 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 220 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.04 sec (5.5 MB/sec) [smoker] check changes HTML... [smoker] download solr-8.0.0-src.tgz... [smoker] 51.8 MB in 2.91 sec (17.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.tgz... [smoker] 146.0 MB in 6.88 sec (21.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.zip... [smoker] 147.0 MB in 2.57 sec (57.1 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-8.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-8.0.0.tgz... [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8 [smoker] Creating Solr home directory /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [|] [/] [-] [\] [|] [/] [-]
[jira] [Created] (SOLR-11655) SolrCloud should Support encrypted zookeeper ACL Digest details
Parvez Kazi created SOLR-11655: -- Summary: SolrCloud should Support encrypted zookeeper ACL Digest details Key: SOLR-11655 URL: https://issues.apache.org/jira/browse/SOLR-11655 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Parvez Kazi In SolrCloud, to connect to zookeeper, we need to provide zookeeper credentials and acls in below format : (plain text) SOLR_ZK_CREDS_AND_ACLS="-DzkACLProvider=org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider \ -DzkCredentialsProvider=org.apache.solr.common.cloud.VMParamsSingleSetCredentialsDigestZkCredentialsProvider \ -DzkDigestUsername=admin -DzkDigestPassword=admin123 \ -DzkDigestReadonlyUsername=admin -DzkDigestReadonlyPassword=admin123" We want to have these credentials in encrypted format. Do we have this supported and if yes how to implement? If not, is this planned in future releases? Please update on this,. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+29) - Build # 20932 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20932/ Java: 64bit/jdk-10-ea+29 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.ref_guide_examples.UsingSolrJRefGuideExamplesTest Error Message: Error from server at https://127.0.0.1:45221/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:45221/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([AC41292A0D1C9F6B]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.ref_guide_examples.UsingSolrJRefGuideExamplesTest.setUpCluster(UsingSolrJRefGuideExamplesTest.java:65) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 15027 lines...] [junit4] Suite: org.apache.solr.client.ref_guide_examples.UsingSolrJRefGuideExamplesTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-solrj/test/J0/temp/solr.client.ref_guide_examples.UsingSolrJRefGuideExamplesTest_AC41292A0D1C9F6B-001/init-core-data-001 [junit4] 2> 80140 INFO (SUITE-UsingSolrJRefGuideExamplesTest-seed#[AC41292A0D1C9F6B]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 80140 INFO (SUITE-UsingSolrJRefGuideExamplesTest-seed#[AC41292A0D1C9F6B]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: @org.apache.solr.util.RandomizeSSL(reason="", ssl=0.0/0.0, value=0.0/0.0, clientAuth=0.0/0.0) [junit4]
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.1) - Build # 838 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/838/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: org.apache.solr.cloud.DistribJoinFromCollectionTest.testNoScore Error Message: Error from server at http://127.0.0.1:41103/solr/to_2x2: SolrCloud join: Collection 'from_1x4Alias' not found! Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:41103/solr/to_2x2: SolrCloud join: Collection 'from_1x4Alias' not found! at __randomizedtesting.SeedInfo.seed([99D491A3C0218E03:265B9D113E6D914F]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.DistribJoinFromCollectionTest.testJoins(DistribJoinFromCollectionTest.java:173) at org.apache.solr.cloud.DistribJoinFromCollectionTest.testNoScore(DistribJoinFromCollectionTest.java:121) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 309 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/309/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseParallelGC 2 tests failed. FAILED: org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter Error Message: Collection not found: withShardField Stack Trace: org.apache.solr.common.SolrException: Collection not found: withShardField at __randomizedtesting.SeedInfo.seed([C0B05C095E06CA4B:95E0B49BF2FF05BB]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:850) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233) at org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 309 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/309/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestJmxIntegration Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields\segments_1: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields\segments_1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields\segments_1: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001\init-core-data-001\spellcheckerMultipleFields\segments_1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestJmxIntegration_F44F553ECE20C91B-001 at __randomizedtesting.SeedInfo.seed([F44F553ECE20C91B]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 11562 lines...] [junit4] Suite: org.apache.solr.core.TestJmxIntegration [junit4] 2> Creating dataDir:
[JENKINS] Lucene-Solr-Tests-7.x - Build # 243 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/243/ 2 tests failed. FAILED: org.apache.solr.cloud.TestDeleteCollectionOnDownNodes.deleteCollectionWithDownNodes Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([97AFBC2E2CA1B4F7:99AD8D60A82F87F]:0) at org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269) at org.apache.solr.cloud.TestDeleteCollectionOnDownNodes.deleteCollectionWithDownNodes(TestDeleteCollectionOnDownNodes.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testReadApi Error Message: expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([97AFBC2E2CA1B4F7:C086479BF75356EC]:0) at org.junit.Assert.fail(Assert.java:93) at
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_144) - Build # 20930 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20930/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC 4 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:37359 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:37359 at __randomizedtesting.SeedInfo.seed([E62EC75AE14E20FD:6E7AF8804FB24D05]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:314) 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)
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_144) - Build # 7021 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7021/ Java: 32bit/jdk1.8.0_144 -server -XX:+UseSerialGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.search.TestSearcherManager Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001\_4.si: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001\_4.si C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001\_4.si: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001\TestSearcherManager-001\_4.si C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestSearcherManager_8FA11F2374696EE7-001 at __randomizedtesting.SeedInfo.seed([8FA11F2374696EE7]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.lucene.store.TestSimpleFSDirectory Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_8FA11F2374696EE7-001\tempDir-003: java.nio.file.NoSuchFileException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_8FA11F2374696EE7-001\tempDir-003 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_8FA11F2374696EE7-001\tempDir-003: java.nio.file.NoSuchFileException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_8FA11F2374696EE7-001\tempDir-003 at __randomizedtesting.SeedInfo.seed([8FA11F2374696EE7]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at
[jira] [Commented] (LUCENE-6943) Jvm Crashes occassionaly with Lucene 4.6.1
[
https://issues.apache.org/jira/browse/LUCENE-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256160#comment-16256160
]
Chris A. Mattmann commented on LUCENE-6943:
---
We are seeing something that looks like this bug in Apache OODT:
https://github.com/apache/oodt/blob/1.2.1/core/pom.xml#L290 and while testing
Apache DRAT on our drat-vm Ubuntu box. We are using Lucene core 6.1.0. Have
others seen this in 6.1.0?
> Jvm Crashes occassionaly with Lucene 4.6.1
> --
>
> Key: LUCENE-6943
> URL: https://issues.apache.org/jira/browse/LUCENE-6943
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring
>Affects Versions: 4.6.1
>Reporter: amit bhengra
> Attachments: hs_err_pid9254.log, hs_err_pid9889.log
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7f5625212cd7, pid=9889, tid=139920130201344
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build
> 1.7.0_60-b19)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode
> linux-amd64 )
> # Problematic frame:
> # J 11490 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126
> bytes) @ 0x7f5625212cd7 [0x7f5625212c80+0x57]
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.sun.com/bugreport/crash.jsp
> #
> Register to memory mapping:
> RAX=0x7f55de053510 is an oop
> {instance class}
> - klass: {other class}
> RBX=0x7f549dffc028 is an oop
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader
> - klass: 'org/apache/lucene/codecs/lucene41/Lucene41PostingsReader'
> RCX=0x0004 is an unknown value
> RDX=0x0080 is an unknown value
> RSP=0x7f41b1a7f640 is pointing into the stack for thread:
> 0x7f48f81a4000
> RBP=0x7f4b1bff3630 is an oop
> java.nio.DirectByteBufferR
> - klass: 'java/nio/DirectByteBufferR'
> RSI=0x7f4b1bff35a8 is an oop
> org.apache.lucene.store.MMapDirectory$MMapIndexInput
> - klass: 'org/apache/lucene/store/MMapDirectory$MMapIndexInput'
> RDI=0x237c532a is an unknown value
> R8 =0x237c4da3 is an unknown value
> R9 =0x7f4b1bff35a8 is an oop
> org.apache.lucene.store.MMapDirectory$MMapIndexInput
> - klass: 'org/apache/lucene/store/MMapDirectory$MMapIndexInput'
> R10=0x7f3a8f98a000 is an unknown value
> R11=0x237c4da3 is an unknown value
> R12=0x7f41b1a81f30 is pointing into the stack for thread:
> 0x7f48f81a4000
> R13=0x0093 is an unknown value
> R14=0x431f is an unknown value
> R15=0x7f48f81a4000 is a thread
> Stack: [0x7f41b1985000,0x7f41b1a86000], sp=0x7f41b1a7f640, free
> space=1001k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> J 11490 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126
> bytes) @ 0x7f5625212cd7 [0x7f5625212c80+0x57]
> J 4940 C2
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextPosition()I
> (118 bytes) @ 0x7f5624515cb4 [0x7f5624515980+0x334]
> J 10578 C2 org.apache.lucene.search.ExactPhraseScorer.phraseFreq()I (624
> bytes) @ 0x7f56256de588 [0x7f56256de4e0+0xa8]
> J 10629 C2 org.apache.lucene.search.ExactPhraseScorer.advance(I)I (152 bytes)
> @ 0x7f5625729d84 [0x7f5625729ba0+0x1e4]
> J 10433 C2 org.apache.lucene.search.MinShouldMatchSumScorer.advance(I)I (113
> bytes) @ 0x7f5625653c34 [0x7f5625653ae0+0x154]
> J 5630 C2 org.apache.lucene.search.BooleanScorer2.advance(I)I (14 bytes) @
> 0x7f5624642a10 [0x7f5624642820+0x1f0]
> J 5826 C2 org.apache.lucene.search.DisjunctionScorer.advance(I)I (87 bytes) @
> 0x7f56246f140c [0x7f56246f13c0+0x4c]
> J 8801 C2
> org.apache.lucene.search.join.FkToChildBlockJoinQuery$FkToChildBlockJoinScorer.advance(I)I
> (284 bytes) @ 0x7f56251274c0 [0x7f5625127440+0x80]
> J 5630 C2 org.apache.lucene.search.BooleanScorer2.advance(I)I (14 bytes) @
> 0x7f56246429fc [0x7f5624642820+0x1dc]
> J 4797 C2
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.score(Lorg/apache/lucene/search/Collector;)V
> (91 bytes) @ 0x7f56244e9ccc [0x7f56244e9c40+0x8c]
> J 4613 C2
> org.apache.lucene.search.IndexSearcher.search(Ljava/util/List;Lorg/apache/lucene/search/Weight;Lorg/apache/lucene/search/Collector;)V
> (93 bytes) @ 0x7f562446cbec [0x7f562446ca80+0x16c]
> J 6159 C2
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(Lorg/apache/solr/search/SolrIndexSearcher$QueryResult;Lorg/apache/solr/search/SolrIndexSearcher$QueryCommand;)V
> (708 bytes) @ 0x7f562486cc30
[jira] [Commented] (SOLR-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16256127#comment-16256127 ] Peter Rusko commented on SOLR-8389: --- Hi Amrit, I didn't have as much time as I wanted, but finally, here's the patch. This doesn't let you set up the properties at the collection creation, but I can add that too if it's needed. Let me know what you think. Thanks, Peter > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-8389.patch > > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- 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-8389) Convert CDCR peer cluster and other configurations into collection properties modifiable via APIs
[ https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Rusko updated SOLR-8389: -- Attachment: SOLR-8389.patch > Convert CDCR peer cluster and other configurations into collection properties > modifiable via APIs > - > > Key: SOLR-8389 > URL: https://issues.apache.org/jira/browse/SOLR-8389 > Project: Solr > Issue Type: Improvement > Components: CDCR, SolrCloud >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-8389.patch > > > CDCR configuration is kept inside solrconfig.xml which makes it difficult to > add or change peer cluster configuration. > I propose to move all CDCR config to collection level properties in cluster > state so that they can be modified using the existing modify collection API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1421 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1421/ 11 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZk2Test.test Error Message: KeeperErrorCode = Session expired for /clusterstate.json Stack Trace: org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /clusterstate.json at __randomizedtesting.SeedInfo.seed([DA68999B03709396:523CA641AD8CFE6E]:0) at org.apache.zookeeper.KeeperException.create(KeeperException.java:127) at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1212) at org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:332) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:332) at org.apache.solr.common.cloud.ZkStateReader.refreshLegacyClusterState(ZkStateReader.java:586) at org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:352) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.updateMappingsFromZk(AbstractFullDistribZkTestBase.java:673) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1310) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1301) at org.apache.solr.cloud.BasicDistributedZk2Test.brindDownShardIndexSomeDocsAndRecover(BasicDistributedZk2Test.java:301) at org.apache.solr.cloud.BasicDistributedZk2Test.test(BasicDistributedZk2Test.java:108) 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
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 836 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/836/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseParallelGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=7449, name=searcherExecutor-2996-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=7449, name=searcherExecutor-2996-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([9456941E0CE34599]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=7449, name=searcherExecutor-2996-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=7449, name=searcherExecutor-2996-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([9456941E0CE34599]:0) FAILED: org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest Error Message: Timeout waiting for all live and active Stack Trace: java.lang.AssertionError: Timeout waiting for all live and active at __randomizedtesting.SeedInfo.seed([9456941E0CE34599:E0A6755B48C70216]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest(TestCloudRecovery.java:99) 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
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+29) - Build # 20929 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20929/ Java: 64bit/jdk-10-ea+29 -XX:-UseCompressedOops -XX:+UseG1GC 4 tests failed. FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:41929/c_yx/z Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:41929/c_yx/z at __randomizedtesting.SeedInfo.seed([DE3BD6B4D4A33BBA:566FE96E7A5F5642]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1668) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1695) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:610) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152) 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 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
[jira] [Closed] (SOLR-11536) Solr Index Partition by Timestamp(day)
[ https://issues.apache.org/jira/browse/SOLR-11536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley closed SOLR-11536. --- > Solr Index Partition by Timestamp(day) > -- > > Key: SOLR-11536 > URL: https://issues.apache.org/jira/browse/SOLR-11536 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: David Cuesta Merino > > I am using Solr Cloud for indexing a big amount of log data files. Should it > be necessary to partition the index? We have thought about partitioning the > index by timestamp(day). > I have not found any document about how to partition an Index in Solr Cloud > by different components(day, hour...) of a timestamp. > How that should be done? -- 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-11654) TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to the ideal shard
David Smiley created SOLR-11654:
---
Summary:
TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to
the ideal shard
Key: SOLR-11654
URL: https://issues.apache.org/jira/browse/SOLR-11654
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCloud
Reporter: David Smiley
{{TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection}} looks up the
Shard/Slice to talk to for the given collection. It currently picks the first
active Shard/Slice but it has a TODO to route to the ideal one based on the
router configuration of the target collection. There is similar code in
CloudSolrClient & DistributedUpdateProcessor that should probably be
refactored/standardized so that we don't have to repeat this logic.
--
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-11653) create next time collection based on a fixed time gap
David Smiley created SOLR-11653: --- Summary: create next time collection based on a fixed time gap Key: SOLR-11653 URL: https://issues.apache.org/jira/browse/SOLR-11653 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: David Smiley For time series collections (as part of a collection Alias with certain metadata), we want to automatically add new collections. In this issue, this is about creating the next collection based on a configurable fixed time gap. And we will also add this collection synchronously once a document flowing through the URP chain exceeds the gap, as opposed to asynchronously in advance. There will be some Alias metadata to define in this issue. The preponderance of the implementation will be in TimePartitionedUpdateProcessor or perhaps a helper to this URP. note: other issues will implement pre-emptive creation and capping collections by size. -- 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-11542) Add URP to route time partitioned collections
[ https://issues.apache.org/jira/browse/SOLR-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-11542. - Resolution: Fixed Assignee: David Smiley Committed. Before this is usable to many users, we still need SOLR-11617 to set Alias metadata via an API. Further issues will make it more useful, like adding and removing collections automatically. > Add URP to route time partitioned collections > - > > Key: SOLR-11542 > URL: https://issues.apache.org/jira/browse/SOLR-11542 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley > Fix For: 7.2 > > Attachments: SOLR_11542_time_series_URP.patch, > SOLR_11542_time_series_URP.patch, SOLR_11542_time_series_URP.patch > > > Assuming we have some time partitioning metadata on an alias (see SOLR-11487 > for the metadata facility), we'll then need to route documents to the right > collection. I propose a new URP. _(edit: originally it was thought > DistributedURP would be modified but thankfully we can avoid that)._ > The scope of this issue is: > * decide on some alias metadata names & semantics > * decide the collection suffix pattern. Read/write code (needed to route). > * the routing code > No new partition creation nor deletion happens is this issue. -- 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-Solaris (64bit/jdk1.8.0) - Build # 1534 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1534/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([40E3EEBE44A671BF:C8B7D164EA5A1C47]:0) at org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.java:109) 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.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 12303 lines...] [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerConcurrent [junit4] 2> Creating
[jira] [Commented] (SOLR-11542) Add URP to route time partitioned collections
[ https://issues.apache.org/jira/browse/SOLR-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255895#comment-16255895 ] ASF subversion and git services commented on SOLR-11542: Commit 81a9637fd0288851a56ce3c957fbaf267b1ad696 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81a9637 ] SOLR-11542: TimePartitionedUpdateProcessor URP (cherry picked from commit df5a5f9) > Add URP to route time partitioned collections > - > > Key: SOLR-11542 > URL: https://issues.apache.org/jira/browse/SOLR-11542 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley > Fix For: 7.2 > > Attachments: SOLR_11542_time_series_URP.patch, > SOLR_11542_time_series_URP.patch, SOLR_11542_time_series_URP.patch > > > Assuming we have some time partitioning metadata on an alias (see SOLR-11487 > for the metadata facility), we'll then need to route documents to the right > collection. I propose a new URP. _(edit: originally it was thought > DistributedURP would be modified but thankfully we can avoid that)._ > The scope of this issue is: > * decide on some alias metadata names & semantics > * decide the collection suffix pattern. Read/write code (needed to route). > * the routing code > No new partition creation nor deletion happens is this issue. -- 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-11542) Add URP to route time partitioned collections
[ https://issues.apache.org/jira/browse/SOLR-11542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255893#comment-16255893 ] ASF subversion and git services commented on SOLR-11542: Commit df5a5f949b1a28feff0cc25fe13c95b502feac31 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df5a5f9 ] SOLR-11542: TimePartitionedUpdateProcessor URP > Add URP to route time partitioned collections > - > > Key: SOLR-11542 > URL: https://issues.apache.org/jira/browse/SOLR-11542 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley > Fix For: 7.2 > > Attachments: SOLR_11542_time_series_URP.patch, > SOLR_11542_time_series_URP.patch, SOLR_11542_time_series_URP.patch > > > Assuming we have some time partitioning metadata on an alias (see SOLR-11487 > for the metadata facility), we'll then need to route documents to the right > collection. I propose a new URP. _(edit: originally it was thought > DistributedURP would be modified but thankfully we can avoid that)._ > The scope of this issue is: > * decide on some alias metadata names & semantics > * decide the collection suffix pattern. Read/write code (needed to route). > * the routing code > No new partition creation nor deletion happens is this issue. -- 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-11601) solr.LatLonPointSpatialField : sorting by geodist fails
[
https://issues.apache.org/jira/browse/SOLR-11601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255877#comment-16255877
]
Amrit Sarkar commented on SOLR-11601:
-
Hi Clemens,
It doesn't fails it is *intended behavior.* I replicated your scenario on my
system and it threw this stack trace:
{code}
Caused by: org.apache.solr.common.SolrException: A ValueSource isn't directly
available from this field. Instead try a query using the distance as the score.
at
org.apache.solr.schema.AbstractSpatialFieldType.getValueSource(AbstractSpatialFieldType.java:334)
at
org.apache.solr.search.FunctionQParser.parseValueSource(FunctionQParser.java:384)
at
org.apache.solr.search.FunctionQParser.parseValueSourceList(FunctionQParser.java:227)
at
org.apache.solr.search.function.distance.GeoDistValueSourceParser.parse(GeoDistValueSourceParser.java:54)
at
org.apache.solr.search.FunctionQParser.parseValueSource(FunctionQParser.java:370)
at org.apache.solr.search.FunctionQParser.parse(FunctionQParser.java:82)
at org.apache.solr.search.QParser.getQuery(QParser.java:168)
at
org.apache.solr.search.SortSpecParsing.parseSortSpecImpl(SortSpecParsing.java:120)
... 37 more
{code}
When I looked at: at
org.apache.solr.schema.AbstractSpatialFieldType.getValueSource(AbstractSpatialFieldType.java:334)
{code}
@Override
public ValueSource getValueSource(SchemaField field, QParser parser) {
//This is different from Solr 3 LatLonType's approach which uses the
MultiValueSource concept to directly expose
// the x & y pair of FieldCache value sources.
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
"A ValueSource isn't directly available from this field. Instead try a
query using the distance as the score.");
}
{code}
_This function only implements this particular use-case and throws that
particular exception._
You should keep using
{{sfield=b4_location__geo_si=47.36667,8.55=geodist() asc}} as it is
neat too, as comparison to geodist(...,...,...).
> solr.LatLonPointSpatialField : sorting by geodist fails
> ---
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Priority: Blocker
>
> Im switching my schemas from derprecated solr.LatLonType to
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort using syntax
> {color:#14892c}sfield=b4_location__geo_si=47.36667,8.55=geodist() asc
> works as expected though...{color}
--
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-11652) Cdcr TLogs doesn't get purged for Source collection Leader when Buffer is disabled from CDCR API
Amrit Sarkar created SOLR-11652: --- Summary: Cdcr TLogs doesn't get purged for Source collection Leader when Buffer is disabled from CDCR API Key: SOLR-11652 URL: https://issues.apache.org/jira/browse/SOLR-11652 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Amrit Sarkar Cdcr transactions logs doesn't get purged on leader EVER when Buffer DISABLED from CDCR API. More details to follow. -- 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-11487) Collection Alias metadata for time partitioned collections
[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-11487.
-
Resolution: Fixed
Finally committed! Thanks for your work on this Gus and my endless code
reviews ;-)
> Collection Alias metadata for time partitioned collections
> --
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a
> series of collections of a time series. We'll need to store some metadata
> about these time series collections, such as which field of the document
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper)
> will break_. Although if it's configured with an HTTP Solr URL then it would
> not break. There's also some read/write hassle to worry about -- we may need
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say,
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the
> configset in use?
--
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-11487) Collection Alias metadata for time partitioned collections
[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255784#comment-16255784
]
ASF subversion and git services commented on SOLR-11487:
Commit 6d9f6cda1a0fa6a48e36a153f69a8aa2cfcd943f in lucene-solr's branch
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6d9f6cd ]
SOLR-11487: Collection Aliases may now have metadata
(cherry picked from commit fd1820a)
> Collection Alias metadata for time partitioned collections
> --
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a
> series of collections of a time series. We'll need to store some metadata
> about these time series collections, such as which field of the document
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper)
> will break_. Although if it's configured with an HTTP Solr URL then it would
> not break. There's also some read/write hassle to worry about -- we may need
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say,
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the
> configset in use?
--
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-11487) Collection Alias metadata for time partitioned collections
[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255782#comment-16255782
]
ASF subversion and git services commented on SOLR-11487:
Commit fd1820a430c321e6a2b2910004d7d2be60d3db4a in lucene-solr's branch
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fd1820a ]
SOLR-11487: Collection Aliases may now have metadata
> Collection Alias metadata for time partitioned collections
> --
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a
> series of collections of a time series. We'll need to store some metadata
> about these time series collections, such as which field of the document
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper)
> will break_. Although if it's configured with an HTTP Solr URL then it would
> not break. There's also some read/write hassle to worry about -- we may need
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say,
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the
> configset in use?
--
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-8050) PerFieldDocValuesFormat's merge should not grab field DVF if DocValuesType.NONE
[
https://issues.apache.org/jira/browse/LUCENE-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-8050:
-
Attachment: LUCENE_8050.patch
Here's a patch. I can write a test.
WDYT [~mikemccand] -- you shepherded in LUCENE-7456.
> PerFieldDocValuesFormat's merge should not grab field DVF if
> DocValuesType.NONE
> ---
>
> Key: LUCENE-8050
> URL: https://issues.apache.org/jira/browse/LUCENE-8050
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Affects Versions: 6.3
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: LUCENE_8050.patch
>
>
> Since LUCENE-7456 (Lucene 6.3), PerFieldDocValuesFormat delegates the merge
> to the actual field DVF's merge. Great, but unfortunately it will call
> {{getDocValuesFormatForField}} on all fields (in FieldInfos) even those that
> have no DocValues (DocValuesType.NONE). It won't ultimately actually write
> anything to those DVFs but there may be some overhead and furthermore it's
> now more awkward to write a subclass of PFDVF that deliberately throws an
> exception from {{getDocValuesFormatForField}} for some fields.
> AFAICT this appears to be a non-issue for PerFieldPostingsFormat's merge
> because it's use of MultiFields filters out IndexOptions.NONE
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8050) PerFieldDocValuesFormat's merge should not grab field DVF if DocValuesType.NONE
David Smiley created LUCENE-8050:
Summary: PerFieldDocValuesFormat's merge should not grab field DVF
if DocValuesType.NONE
Key: LUCENE-8050
URL: https://issues.apache.org/jira/browse/LUCENE-8050
Project: Lucene - Core
Issue Type: Improvement
Components: core/index
Affects Versions: 6.3
Reporter: David Smiley
Assignee: David Smiley
Since LUCENE-7456 (Lucene 6.3), PerFieldDocValuesFormat delegates the merge to
the actual field DVF's merge. Great, but unfortunately it will call
{{getDocValuesFormatForField}} on all fields (in FieldInfos) even those that
have no DocValues (DocValuesType.NONE). It won't ultimately actually write
anything to those DVFs but there may be some overhead and furthermore it's now
more awkward to write a subclass of PFDVF that deliberately throws an exception
from {{getDocValuesFormatForField}} for some fields.
AFAICT this appears to be a non-issue for PerFieldPostingsFormat's merge
because it's use of MultiFields filters out IndexOptions.NONE
--
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 # 20928 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20928/ Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseParallelGC 2 tests failed. FAILED: org.apache.solr.cloud.TestExclusionRuleCollectionAccess.doTest Error Message: Error from server at https://127.0.0.1:37153/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:37153/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([B72ED3C6D6E86516:106A6B62BB5376AF]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.TestExclusionRuleCollectionAccess.doTest(TestExclusionRuleCollectionAccess.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-11487) Collection Alias metadata for time partitioned collections
[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255683#comment-16255683
]
Gus Heck commented on SOLR-11487:
-
* Bug: heh, I almost wrote a test for that too... I clearly should have. Thx
* Love the elimination of the top map. definitely cleaner.
* Less Clone... yes you've done a nice job of actually cashing in on our
immutability there. That's a very logical thing to do.
Other stuff good too... Map.replaceAll()... cool! :).
All looks good to me. Does look cleaner overall. One other really nice benefit
here is by eliminating the top map we eliminated almost all the unchecked cast
stuff, only 2 methods need it now, and the class level @SuppressWarnings can go
away I think.
> Collection Alias metadata for time partitioned collections
> --
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a
> series of collections of a time series. We'll need to store some metadata
> about these time series collections, such as which field of the document
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper)
> will break_. Although if it's configured with an HTTP Solr URL then it would
> not break. There's also some read/write hassle to worry about -- we may need
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say,
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the
> configset in use?
--
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-11553) facet refinement can use wrong access method
[ https://issues.apache.org/jira/browse/SOLR-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-11553. - Resolution: Fixed Assignee: Yonik Seeley > facet refinement can use wrong access method > > > Key: SOLR-11553 > URL: https://issues.apache.org/jira/browse/SOLR-11553 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.0 >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 7.2 > > Attachments: SOLR-11553.patch > > > First and second phase faceting can use different access methods (UIF in > phase one, DV in phase 2) resulting in too much memory use. -- 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-11553) facet refinement can use wrong access method
[ https://issues.apache.org/jira/browse/SOLR-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255644#comment-16255644 ] ASF subversion and git services commented on SOLR-11553: Commit cf2e4d7dced9905795350d41c2fd4470be00fced in lucene-solr's branch refs/heads/branch_7x from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf2e4d7 ] SOLR-11553: fix refinement to pick right processor / uninversion mechanism > facet refinement can use wrong access method > > > Key: SOLR-11553 > URL: https://issues.apache.org/jira/browse/SOLR-11553 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.0 >Reporter: Yonik Seeley > Fix For: 7.2 > > Attachments: SOLR-11553.patch > > > First and second phase faceting can use different access methods (UIF in > phase one, DV in phase 2) resulting in too much memory use. -- 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-11553) facet refinement can use wrong access method
[ https://issues.apache.org/jira/browse/SOLR-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255643#comment-16255643 ] ASF subversion and git services commented on SOLR-11553: Commit c561ffe6350965716222a8afb29ac72d29060b5c in lucene-solr's branch refs/heads/master from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c561ffe ] SOLR-11553: fix refinement to pick right processor / uninversion mechanism > facet refinement can use wrong access method > > > Key: SOLR-11553 > URL: https://issues.apache.org/jira/browse/SOLR-11553 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.0 >Reporter: Yonik Seeley > Fix For: 7.2 > > Attachments: SOLR-11553.patch > > > First and second phase faceting can use different access methods (UIF in > phase one, DV in phase 2) resulting in too much memory use. -- 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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer
[ https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255640#comment-16255640 ] Alan Woodward commented on LUCENE-6228: --- bq. What we need to prevent is someone calling advance() based on the results of getChildren But the current patch does that by just not having getChildren() on Scorable. And just as you can get round that by casting, you could cast ChildScorer.child to a Scorer as well if you wanted to. I guess the disagreement is over what the getChildren() API is actually for. The tests are using it to check that constant score wrappers and the like are still giving us the correct root scorer, so I think casting is OK there? Another idea I had was to replace getChildren() entirely with a visitor API, and have a method like IndexSearcher.explain(). So you call searcher.visitScorers(Query q, int doc, ScorerVisitor visitor) and it will then visit all the scorers that are positioned on that doc. Maybe I should open another issue to deal with that first? > Do not expose full-fledged scorers in LeafCollector.setScorer > - > > Key: LUCENE-6228 > URL: https://issues.apache.org/jira/browse/LUCENE-6228 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand > Fix For: 5.2, 6.0 > > Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, > LUCENE-6228.patch > > > Currently LeafCollector.setScorer takes a Scorer, which I don't like because > several methods should never be called in the context of a Collector (like > nextDoc or advance). > I think it's even more trappy for methods that might seem to work in some > particular cases but will not work in the general case, like getChildren > which will not work if you have a specialized BulkScorer or iterating over > positions which will not work if you are in a MultiCollector and another leaf > collector consumes positions too. > So I think we should restrict what can be seen from a collector to avoid such > traps. -- 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-11651) Solr Resources web page should highlight the ref guide section
[ https://issues.apache.org/jira/browse/SOLR-11651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-11651: - Description: Under the Documentation section, we have a very small description of what the ref guide is . We also list the Javadocs before this ( which is very sparse ) Let's highlight the ref guide which we put a lot of effort in maintaining and encourage users to click on that over the Javadocs Resources Page : http://lucene.apache.org/solr/resources.html was: Under the Documentation section, we have a very small description of what the ref guide is . We also list the Javadocs before this ( which is very sparse ) Let's highlight the ref guide which we put a lot of effort in maintaining and encourage users to click on that over the Javadocs > Solr Resources web page should highlight the ref guide section > -- > > Key: SOLR-11651 > URL: https://issues.apache.org/jira/browse/SOLR-11651 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > > Under the Documentation section, we have a very small description of what the > ref guide is . We also list the Javadocs before this ( which is very sparse ) > Let's highlight the ref guide which we put a lot of effort in maintaining and > encourage users to click on that over the Javadocs > Resources Page : http://lucene.apache.org/solr/resources.html -- 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-11651) Solr Resources web page should highlight the ref guide section
Varun Thacker created SOLR-11651: Summary: Solr Resources web page should highlight the ref guide section Key: SOLR-11651 URL: https://issues.apache.org/jira/browse/SOLR-11651 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Varun Thacker Priority: Minor Under the Documentation section, we have a very small description of what the ref guide is . We also list the Javadocs before this ( which is very sparse ) Let's highlight the ref guide which we put a lot of effort in maintaining and encourage users to click on that over the Javadocs -- 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-11251) Ref Guide: Add docs on JSON facet module
[
https://issues.apache.org/jira/browse/SOLR-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-11251.
-
Resolution: Fixed
Fix Version/s: 7.2
> Ref Guide: Add docs on JSON facet module
>
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
> Fix For: 7.2
>
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON
> facets, 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.
> The doc was never updated after any of the changes that have been made to
> JSON facet functionality since it was originally written, so it's possibly
> inaccurate or just out of date. Someone could take a crack at finishing the
> conversion cleanup and updating it with latest information so someday it can
> be part of the published 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-11251) Ref Guide: Add docs on JSON facet module
[
https://issues.apache.org/jira/browse/SOLR-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255533#comment-16255533
]
ASF subversion and git services commented on SOLR-11251:
Commit a44afc55a54f6a228ffe36a7ff317be53e8052a9 in lucene-solr's branch
refs/heads/branch_7x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a44afc5 ]
SOLR-11251: docs - JSON Facet API
> Ref Guide: Add docs on JSON facet module
>
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON
> facets, 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.
> The doc was never updated after any of the changes that have been made to
> JSON facet functionality since it was originally written, so it's possibly
> inaccurate or just out of date. Someone could take a crack at finishing the
> conversion cleanup and updating it with latest information so someday it can
> be part of the published 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-11251) Ref Guide: Add docs on JSON facet module
[
https://issues.apache.org/jira/browse/SOLR-11251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255529#comment-16255529
]
ASF subversion and git services commented on SOLR-11251:
Commit 96af869da365cb11288647123d755f35b8aabb25 in lucene-solr's branch
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=96af869 ]
SOLR-11251: docs - JSON Facet API
> Ref Guide: Add docs on JSON facet module
>
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON
> facets, 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.
> The doc was never updated after any of the changes that have been made to
> JSON facet functionality since it was originally written, so it's possibly
> inaccurate or just out of date. Someone could take a crack at finishing the
> conversion cleanup and updating it with latest information so someday it can
> be part of the published 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
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.1) - Build # 834 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/834/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=8423, name=searcherExecutor-3624-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=8423, name=searcherExecutor-3624-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([8106A8D0C820]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=8423, name=searcherExecutor-3624-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=8423, name=searcherExecutor-3624-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([8106A8D0C820]:0) FAILED: org.apache.solr.core.TestLazyCores.testNoCommit Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([8106A8D0C820:5E24E5D763F7AB85]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:901) at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:847) at org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:829) at
[jira] [Commented] (LUCENE-6228) Do not expose full-fledged scorers in LeafCollector.setScorer
[ https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255483#comment-16255483 ] Robert Muir commented on LUCENE-6228: - I don't agree, sorry. We don't need to prevent anyone from calling getChildren() on a FakeScorer, it can just return empty which is the default implementation. What we need to prevent is someone calling advance() based on the results of getChildren, that is key: and honestly if we can't prevent that with this issue, then the abstraction isn't right, its the whole point of doing this :) Stuff like what getChildren() on a FakeScorer or BulkScorer does, that stuff is harmless, and those things are the separate issues that we shouldnt worry about. > Do not expose full-fledged scorers in LeafCollector.setScorer > - > > Key: LUCENE-6228 > URL: https://issues.apache.org/jira/browse/LUCENE-6228 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand > Fix For: 5.2, 6.0 > > Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, > LUCENE-6228.patch > > > Currently LeafCollector.setScorer takes a Scorer, which I don't like because > several methods should never be called in the context of a Collector (like > nextDoc or advance). > I think it's even more trappy for methods that might seem to work in some > particular cases but will not work in the general case, like getChildren > which will not work if you have a specialized BulkScorer or iterating over > positions which will not work if you are in a MultiCollector and another leaf > collector consumes positions too. > So I think we should restrict what can be seen from a collector to avoid such > traps. -- 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/jdk-9.0.1) - Build # 308 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/308/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseG1GC 6 tests failed. FAILED: org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions Error Message: Captured an uncaught exception in thread: Thread[id=17, name=ReplicationThread-indexAndTaxo, state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=17, name=ReplicationThread-indexAndTaxo, state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest] at __randomizedtesting.SeedInfo.seed([83826D3FE2634398:C0C8A9FF00FB067]:0) Caused by: java.lang.AssertionError: handler failed too many times: -1 at __randomizedtesting.SeedInfo.seed([83826D3FE2634398]:0) at org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:422) at org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77) FAILED: org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testCursorMarkNoSort Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1\data C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1\data C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005\collection1 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_2ED56BA299266CFF-001\tempDir-005 at __randomizedtesting.SeedInfo.seed([2ED56BA299266CFF:3DE21FAF2C73CC6]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd$SolrInstance.tearDown(TestSolrEntityProcessorEndToEnd.java:360) at org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.tearDown(TestSolrEntityProcessorEndToEnd.java:142) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at
[jira] [Updated] (SOLR-11650) Credentials used for BasicAuth displayed in clear text on slave nodes
[ https://issues.apache.org/jira/browse/SOLR-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amrit Sarkar updated SOLR-11650: Attachment: SOLR-11650.patch Potential patch, I don't have the bandwidth right now to test this out, once I have, will validate whether we can use this patch or post an updated one. > Credentials used for BasicAuth displayed in clear text on slave nodes > - > > Key: SOLR-11650 > URL: https://issues.apache.org/jira/browse/SOLR-11650 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication >Affects Versions: 6.6.2 >Reporter: Constantin Bugneac >Priority: Critical > Attachments: SOLR-11650.patch, Screen Shot 2017-11-16 at 10.48.38.png > > > Pre-requisites: > Have in place Solr configured in master slave replication with BasicAuth > enabled. > Issue: > In UI on slave (under Replication tab of core) the master url is displayed > with username and password used for BasicAuth in clear text. > Example: > master url:https://solr:sdjudf3t...@solr-master.local.com:8983/solr/mycore > (see attached the screenshot) > Suggestion/Idea: > At least mask the password with *** -- 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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer
[ https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255460#comment-16255460 ] Alan Woodward commented on LUCENE-6228: --- The issue with getChildren() is that you can't access it if a BulkScorer is being used - it's a separate problem to this issue, which is preventing people calling iterator() from a Collector. Or rather, it's the same sort of problem, in that we should prevent people from calling getChildren() from a Collector, because they might be holding a FakeScorer which can't support it. > Do not expose full-fledged scorers in LeafCollector.setScorer > - > > Key: LUCENE-6228 > URL: https://issues.apache.org/jira/browse/LUCENE-6228 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand > Fix For: 5.2, 6.0 > > Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, > LUCENE-6228.patch > > > Currently LeafCollector.setScorer takes a Scorer, which I don't like because > several methods should never be called in the context of a Collector (like > nextDoc or advance). > I think it's even more trappy for methods that might seem to work in some > particular cases but will not work in the general case, like getChildren > which will not work if you have a specialized BulkScorer or iterating over > positions which will not work if you are in a MultiCollector and another leaf > collector consumes positions too. > So I think we should restrict what can be seen from a collector to avoid such > traps. -- 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/jdk-9.0.1) - Build # 20927 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20927/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseG1GC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.graph.GraphExpressionTest Error Message: Error from server at https://127.0.0.1:35291/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:35291/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([CE8CD1B9BDD268E1]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.io.graph.GraphExpressionTest.setupCluster(GraphExpressionTest.java:87) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.MoveReplicaHDFSFailoverTest.testOldReplicaIsDeleted Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([D9B8AD0C1B4AE93E:962649D11A40A65C]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.MoveReplicaHDFSFailoverTest.testOldReplicaIsDeleted(MoveReplicaHDFSFailoverTest.java:149) 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)
[jira] [Commented] (LUCENE-6228) Do not expose full-fledged scorers in LeafCollector.setScorer
[
https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255444#comment-16255444
]
Robert Muir commented on LUCENE-6228:
-
{quote}
This just moves the existing problem with getChildren() to the new interface
though? I think I'd rather leave it on Scorer and make it accessible through
IndexSearcher or something similar in a follow-up issue. I can change the tests
in question to not use Collectors.
{quote}
I don't think it does, i think it fixes the API? Instead of the following on
Scorer:
{code}
Collection getChildren();
class ChildScorer {
Scorer child;
relationship;
}
{code}
we should have on Scorable:
{code}
Collection getChildren();
class ChildScorer {
Scorable child;
relationship;
}
{code}
This means that getChildren becomes "safe" and you can't call methods on Scorer
that you shouldnt be invoking. As far as I understand, its part of the
motivation behind this whole issue.
> Do not expose full-fledged scorers in LeafCollector.setScorer
> -
>
> Key: LUCENE-6228
> URL: https://issues.apache.org/jira/browse/LUCENE-6228
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 5.2, 6.0
>
> Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch,
> LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because
> several methods should never be called in the context of a Collector (like
> nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some
> particular cases but will not work in the general case, like getChildren
> which will not work if you have a specialized BulkScorer or iterating over
> positions which will not work if you are in a MultiCollector and another leaf
> collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such
> traps.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 83 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/83/ 7 tests failed. FAILED: org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomBig Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([3E235A0EA737AC2E]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.spatial3d.TestGeo3DPoint Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([3E235A0EA737AC2E]:0) FAILED: org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin Error Message: expected:<0> but was:<2> Stack Trace: java.lang.AssertionError: expected:<0> but was:<2> at __randomizedtesting.SeedInfo.seed([EC8D07AEAB38D403:565F68D628163A16]: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.handler.dataimport.TestContentStreamDataSource.testCommitWithin(TestContentStreamDataSource.java:98) 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
[jira] [Commented] (SOLR-7759) DebugComponent's explain should be implemented as a distributed query
[ https://issues.apache.org/jira/browse/SOLR-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255340#comment-16255340 ] Alessandro Benedetti commented on SOLR-7759: Up, is anyone interested in fixing this problem ? I attached a tentative patch months ago, let me know if anyone is interested and we can work on it to fix it ! > DebugComponent's explain should be implemented as a distributed query > - > > Key: SOLR-7759 > URL: https://issues.apache.org/jira/browse/SOLR-7759 > Project: Solr > Issue Type: Bug >Reporter: Varun Thacker > Attachments: SOLR_7759.patch > > > Currently when we use debugQuery to see the explanation of the matched > documents, the query fired to get the statistics for the matched documents is > not a distributed query. > This is a problem when using distributed idf. The actual documents are being > scored using the global stats and not per shard stats , but the explain will > show us the score by taking into account the stats from the shard where the > document belongs to. > We should try to implement the explain query as a distributed request so that > the scores match the actual document scores. -- 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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer
[ https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255332#comment-16255332 ] Alan Woodward commented on LUCENE-6228: --- bq. Can we try something like moving getChildren from Scorer to this interface This just moves the existing problem with getChildren() to the new interface though? I think I'd rather leave it on Scorer and make it accessible through IndexSearcher or something similar in a follow-up issue. I can change the tests in question to not use Collectors. bq. We should also check performance Will run it through luceneutil and see what happens > Do not expose full-fledged scorers in LeafCollector.setScorer > - > > Key: LUCENE-6228 > URL: https://issues.apache.org/jira/browse/LUCENE-6228 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand > Fix For: 5.2, 6.0 > > Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, > LUCENE-6228.patch > > > Currently LeafCollector.setScorer takes a Scorer, which I don't like because > several methods should never be called in the context of a Collector (like > nextDoc or advance). > I think it's even more trappy for methods that might seem to work in some > particular cases but will not work in the general case, like getChildren > which will not work if you have a specialized BulkScorer or iterating over > positions which will not work if you are in a MultiCollector and another leaf > collector consumes positions too. > So I think we should restrict what can be seen from a collector to avoid such > traps. -- 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-11650) Credentials used for BasicAuth displayed in clear text on slave nodes
[ https://issues.apache.org/jira/browse/SOLR-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255321#comment-16255321 ] Amrit Sarkar commented on SOLR-11650: - I can see the hashed value of the password, its a cakewalk to retrieve password from that. This should be addressed promptly. > Credentials used for BasicAuth displayed in clear text on slave nodes > - > > Key: SOLR-11650 > URL: https://issues.apache.org/jira/browse/SOLR-11650 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication >Affects Versions: 6.6.2 >Reporter: Constantin Bugneac >Priority: Critical > Attachments: Screen Shot 2017-11-16 at 10.48.38.png > > > Pre-requisites: > Have in place Solr configured in master slave replication with BasicAuth > enabled. > Issue: > In UI on slave (under Replication tab of core) the master url is displayed > with username and password used for BasicAuth in clear text. > Example: > master url:https://solr:sdjudf3t...@solr-master.local.com:8983/solr/mycore > (see attached the screenshot) > Suggestion/Idea: > At least mask the password with *** -- 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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer
[ https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255251#comment-16255251 ] Robert Muir commented on LUCENE-6228: - The casts back to Scorer in some of the tests are concerning, because if code just does this then i'm not certain how much this abstraction is helping. Can we try something like moving getChildren from Scorer to this interface (it can still have default empty implementation with a default method)? Then maybe the casts would be removed but also ChildScorer would be restricted (like mentioned in the description of the issue) from doing illegal stuff. We should also check performance, its a bit scary to add interfaces here (maybe an abstract class is an alternative) and we should ensure that this patch isn't causing hotspot to go crazy because of FakeScorer and Scorer impls. > Do not expose full-fledged scorers in LeafCollector.setScorer > - > > Key: LUCENE-6228 > URL: https://issues.apache.org/jira/browse/LUCENE-6228 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand > Fix For: 5.2, 6.0 > > Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, > LUCENE-6228.patch > > > Currently LeafCollector.setScorer takes a Scorer, which I don't like because > several methods should never be called in the context of a Collector (like > nextDoc or advance). > I think it's even more trappy for methods that might seem to work in some > particular cases but will not work in the general case, like getChildren > which will not work if you have a specialized BulkScorer or iterating over > positions which will not work if you are in a MultiCollector and another leaf > collector consumes positions too. > So I think we should restrict what can be seen from a collector to avoid such > traps. -- 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-6228) Do not expose full-fledged scorers in LeafCollector.setScorer
[ https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-6228: -- Attachment: LUCENE-6228.patch Here's a patch implementing [~rcmuir]'s idea of a Scorable interface. This seems like the least intrusive way of doing this? As this changes LeafCollector, which is a fairly heavily-used part of the API, I think this should only apply to master > Do not expose full-fledged scorers in LeafCollector.setScorer > - > > Key: LUCENE-6228 > URL: https://issues.apache.org/jira/browse/LUCENE-6228 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand > Fix For: 5.2, 6.0 > > Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, > LUCENE-6228.patch > > > Currently LeafCollector.setScorer takes a Scorer, which I don't like because > several methods should never be called in the context of a Collector (like > nextDoc or advance). > I think it's even more trappy for methods that might seem to work in some > particular cases but will not work in the general case, like getChildren > which will not work if you have a specialized BulkScorer or iterating over > positions which will not work if you are in a MultiCollector and another leaf > collector consumes positions too. > So I think we should restrict what can be seen from a collector to avoid such > traps. -- 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-11629) CloudSolrClient.Builder should accept a zk host
[
https://issues.apache.org/jira/browse/SOLR-11629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-11629:
---
Attachment: SOLR-11629.patch
The attached patch gets rid of builder ctors (3) and (4), as suggested. I also
added some Javadocs to the remaining constructors.
Tests and precommit pass.
> CloudSolrClient.Builder should accept a zk host
> ---
>
> Key: SOLR-11629
> URL: https://issues.apache.org/jira/browse/SOLR-11629
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11629.patch, SOLR-11629.patch
>
>
> Today we need to create an empty builder and then wither pass zkHost or
> withSolrUrl
> {code}
> SolrClient solrClient = new
> CloudSolrClient.Builder().withZkHost("localhost:9983").build();
> solrClient.request(updateRequest, "gettingstarted");
> {code}
> What if we have two constructors , one that accepts a zkHost and one that
> accepts a SolrUrl .
> The advantages that I can think of are:
> - It will be obvious to users that we support two mechanisms of creating a
> CloudSolrClient . The SolrUrl option is cool and applications don't need to
> know about ZooKeeper and new users will learn about this . Maybe our
> example's on the ref guide should use this?
> - Today people can set both zkHost and solrUrl but CloudSolrClient can only
> utilize one of them
> HttpClient's Builder accepts the host
> {code}
> HttpSolrClient client = new
> HttpSolrClient.Builder("http://localhost:8983/solr;).build();
> client.request(updateRequest, "techproducts");
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+29) - Build # 20926 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20926/ Java: 64bit/jdk-10-ea+29 -XX:+UseCompressedOops -XX:+UseParallelGC 7 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.FullSolrCloudDistribCmdsTest Error Message: 64 threads leaked from SUITE scope at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest: 1) Thread[id=131, name=qtp1676846946-131, state=TIMED_WAITING, group=TGRP-FullSolrCloudDistribCmdsTest] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2116) at app//org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) at app//org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:563) at app//org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:48) at app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)2) Thread[id=95, name=qtp1012523591-95, state=TIMED_WAITING, group=TGRP-FullSolrCloudDistribCmdsTest] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2116) at app//org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:392) at app//org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:563) at app//org.eclipse.jetty.util.thread.QueuedThreadPool.access$800(QueuedThreadPool.java:48) at app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)3) Thread[id=161, name=org.eclipse.jetty.server.session.HashSessionManager@60185359Timer, state=TIMED_WAITING, group=TGRP-FullSolrCloudDistribCmdsTest] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2116) at java.base@10-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182) at java.base@10-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)4) Thread[id=199, name=zkCallback-36-thread-3, state=TIMED_WAITING, group=TGRP-FullSolrCloudDistribCmdsTest] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462) at java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361) at java.base@10-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1060) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)5) Thread[id=121, name=searcherExecutor-46-thread-1, state=WAITING, group=TGRP-FullSolrCloudDistribCmdsTest] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074) at java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061) at
[jira] [Resolved] (LUCENE-7998) Add a DoubleValuesSource that exposes a Query score
[ https://issues.apache.org/jira/browse/LUCENE-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-7998. --- Resolution: Fixed Fix Version/s: 7.2 bq. should not rewrite the values source at rewrite time but at createWeight time I added a javadoc note to this effect. I'll open a separate issue to deprecate CustomScoreQuery, BoostingQuery and BoostedQuery. > Add a DoubleValuesSource that exposes a Query score > --- > > Key: LUCENE-7998 > URL: https://issues.apache.org/jira/browse/LUCENE-7998 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Fix For: 7.2 > > Attachments: LUCENE-7998.patch > > > This will allow us to reproduce the behaviour of BoostingQuery with a > FunctionScoreQuery, either by passing a simple wrapped Query as a single DVS > or by combining several of them using the expressions module. -- 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-7998) Add a DoubleValuesSource that exposes a Query score
[ https://issues.apache.org/jira/browse/LUCENE-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255178#comment-16255178 ] ASF subversion and git services commented on LUCENE-7998: - Commit 2f4ec9bbe2516c4ec62f74656811e89af862ea25 in lucene-solr's branch refs/heads/branch_7x from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2f4ec9b ] LUCENE-7998: CHANGES.txt > Add a DoubleValuesSource that exposes a Query score > --- > > Key: LUCENE-7998 > URL: https://issues.apache.org/jira/browse/LUCENE-7998 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-7998.patch > > > This will allow us to reproduce the behaviour of BoostingQuery with a > FunctionScoreQuery, either by passing a simple wrapped Query as a single DVS > or by combining several of them using the expressions module. -- 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-7998) Add a DoubleValuesSource that exposes a Query score
[ https://issues.apache.org/jira/browse/LUCENE-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255179#comment-16255179 ] ASF subversion and git services commented on LUCENE-7998: - Commit e8dfccca5162314c8e71ae1cffea13d8022b1274 in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e8dfccc ] LUCENE-7998: CHANGES.txt > Add a DoubleValuesSource that exposes a Query score > --- > > Key: LUCENE-7998 > URL: https://issues.apache.org/jira/browse/LUCENE-7998 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-7998.patch > > > This will allow us to reproduce the behaviour of BoostingQuery with a > FunctionScoreQuery, either by passing a simple wrapped Query as a single DVS > or by combining several of them using the expressions module. -- 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-7998) Add a DoubleValuesSource that exposes a Query score
[ https://issues.apache.org/jira/browse/LUCENE-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255175#comment-16255175 ] ASF subversion and git services commented on LUCENE-7998: - Commit 423677f20e6f4405aa8b846f456c75ae7cfc64e0 in lucene-solr's branch refs/heads/master from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=423677f ] LUCENE-7998: QueryDoubleValuesSource > Add a DoubleValuesSource that exposes a Query score > --- > > Key: LUCENE-7998 > URL: https://issues.apache.org/jira/browse/LUCENE-7998 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-7998.patch > > > This will allow us to reproduce the behaviour of BoostingQuery with a > FunctionScoreQuery, either by passing a simple wrapped Query as a single DVS > or by combining several of them using the expressions module. -- 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-7998) Add a DoubleValuesSource that exposes a Query score
[ https://issues.apache.org/jira/browse/LUCENE-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255174#comment-16255174 ] ASF subversion and git services commented on LUCENE-7998: - Commit c6171019d5f460e84e882425eaaa546b011b10ca in lucene-solr's branch refs/heads/branch_7x from [~romseygeek] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c617101 ] LUCENE-7998: QueryDoubleValuesSource > Add a DoubleValuesSource that exposes a Query score > --- > > Key: LUCENE-7998 > URL: https://issues.apache.org/jira/browse/LUCENE-7998 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-7998.patch > > > This will allow us to reproduce the behaviour of BoostingQuery with a > FunctionScoreQuery, either by passing a simple wrapped Query as a single DVS > or by combining several of them using the expressions module. -- 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-11650) Credentials used for BasicAuth displayed in clear text on slave nodes
[ https://issues.apache.org/jira/browse/SOLR-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Constantin Bugneac updated SOLR-11650: -- Description: Pre-requisites: Have in place Solr configured in master slave replication with BasicAuth enabled. Issue: In UI on slave (under Replication tab of core) the master url is displayed with username and password used for BasicAuth in clear text. Example: master url:https://solr:sdjudf3t...@solr-master.local.com:8983/solr/mycore (see attached the screenshot) Suggestion/Idea: At least mask the password with *** was: Pre-requisites: Have in place Solr configured in master slave replication with BasicAuth enabled. Issue: In UI on slave (under Replication tab of core) the master url is displayed with username and password used for BasicAuth in clear text. Example: master url:https://solr:sdjudf3t...@solr-master.local.com:8983/solr/mycore Suggestion/Idea: At least mask the password with *** > Credentials used for BasicAuth displayed in clear text on slave nodes > - > > Key: SOLR-11650 > URL: https://issues.apache.org/jira/browse/SOLR-11650 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication >Affects Versions: 6.6.2 >Reporter: Constantin Bugneac >Priority: Critical > Attachments: Screen Shot 2017-11-16 at 10.48.38.png > > > Pre-requisites: > Have in place Solr configured in master slave replication with BasicAuth > enabled. > Issue: > In UI on slave (under Replication tab of core) the master url is displayed > with username and password used for BasicAuth in clear text. > Example: > master url:https://solr:sdjudf3t...@solr-master.local.com:8983/solr/mycore > (see attached the screenshot) > Suggestion/Idea: > At least mask the password with *** -- 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-11650) Credentials used for BasicAuth displayed in clear text on slave nodes
[ https://issues.apache.org/jira/browse/SOLR-11650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Constantin Bugneac updated SOLR-11650: -- Attachment: Screen Shot 2017-11-16 at 10.48.38.png Example > Credentials used for BasicAuth displayed in clear text on slave nodes > - > > Key: SOLR-11650 > URL: https://issues.apache.org/jira/browse/SOLR-11650 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication >Affects Versions: 6.6.2 >Reporter: Constantin Bugneac >Priority: Critical > Attachments: Screen Shot 2017-11-16 at 10.48.38.png > > > Pre-requisites: > Have in place Solr configured in master slave replication with BasicAuth > enabled. > Issue: > In UI on slave (under Replication tab of core) the master url is displayed > with username and password used for BasicAuth in clear text. > Example: > master url:https://solr:sdjudf3t...@solr-master.local.com:8983/solr/mycore > Suggestion/Idea: > At least mask the password with *** -- 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-11650) Credentials used for BasicAuth displayed in clear text on slave nodes
Constantin Bugneac created SOLR-11650: - Summary: Credentials used for BasicAuth displayed in clear text on slave nodes Key: SOLR-11650 URL: https://issues.apache.org/jira/browse/SOLR-11650 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Authentication Affects Versions: 6.6.2 Reporter: Constantin Bugneac Priority: Critical Pre-requisites: Have in place Solr configured in master slave replication with BasicAuth enabled. Issue: In UI on slave (under Replication tab of core) the master url is displayed with username and password used for BasicAuth in clear text. Example: master url:https://solr:sdjudf3t...@solr-master.local.com:8983/solr/mycore Suggestion/Idea: At least mask the password with *** -- 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 # 832 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/832/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseParallelGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.JDBCStreamTest Error Message: Error starting up MiniSolrCloudCluster Stack Trace: java.lang.Exception: Error starting up MiniSolrCloudCluster at __randomizedtesting.SeedInfo.seed([8D63E55905E5A38E]:0) at org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:507) at org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:251) at org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190) at org.apache.solr.client.solrj.io.stream.JDBCStreamTest.setupCluster(JDBCStreamTest.java:67) 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) Suppressed: java.lang.AssertionError at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getLowerBoundASTs(WildcardTypeImpl.java:94) at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getLowerBounds(WildcardTypeImpl.java:165) at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.toString(WildcardTypeImpl.java:183) at java.lang.reflect.Type.getTypeName(Type.java:46) at sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.toString(ParameterizedTypeImpl.java:234) at java.lang.reflect.Type.getTypeName(Type.java:46) at java.lang.reflect.Method.specificToGenericStringHeader(Method.java:421) at java.lang.reflect.Executable.sharedToGenericString(Executable.java:163) at java.lang.reflect.Method.toGenericString(Method.java:415) at java.beans.MethodRef.set(MethodRef.java:46) at java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:117) at java.beans.MethodDescriptor.(MethodDescriptor.java:72) at java.beans.MethodDescriptor.(MethodDescriptor.java:56) at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1205) at java.beans.Introspector.getBeanInfo(Introspector.java:426) at java.beans.Introspector.getBeanInfo(Introspector.java:173) at java.beans.Introspector.getBeanInfo(Introspector.java:260) at java.beans.Introspector.(Introspector.java:407) at java.beans.Introspector.getBeanInfo(Introspector.java:173) at
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1533 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1533/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation Error Message: 3 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=13933, name=jetty-launcher-2214-thread-1-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) 2) Thread[id=13868, name=jetty-launcher-2214-thread-2-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 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.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323) at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105) at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41) at org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244) at org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44) at org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61) at org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505) 3) Thread[id=13932, name=jetty-launcher-2214-thread-1-SendThread(127.0.0.1:43588), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 3 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=13933, name=jetty-launcher-2214-thread-1-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) 2) Thread[id=13868, name=jetty-launcher-2214-thread-2-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 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.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323) at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105) at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41) at
[jira] [Commented] (SOLR-11645) When there are duplicate java commandline arguments, the Solr UI dashboard doesn't show Args at all
[
https://issues.apache.org/jira/browse/SOLR-11645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255020#comment-16255020
]
Shawn Heisey commented on SOLR-11645:
-
I have created SOLR-11649 for further improvements, and will not attempt to
address sorting in this issue, just duplicate arguments.
> When there are duplicate java commandline arguments, the Solr UI dashboard
> doesn't show Args at all
> ---
>
> Key: SOLR-11645
> URL: https://issues.apache.org/jira/browse/SOLR-11645
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.1
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11645.patch, SOLR-11645.patch
>
>
> A user couldn't get the "Args" to display in the admin UI.
> Ultimately it was determined that they had duplicate arguments on their
> commandline, and this was resulting in an error in the browser:
> {code}
> Error: [ngRepeat:dupes] Duplicates in a repeater are not allowed. Use
> 'track by' expression to specify unique keys. Repeater: arg in
> commandLineArgs, Duplicate key: string:-XX:+UseGCLogFileRotation, Duplicate
> value: -XX:+UseGCLogFileRotation
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11649) Improve "Args" display in admin UI
[
https://issues.apache.org/jira/browse/SOLR-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-11649:
Description:
Followup issue from discussion on SOLR-11645.
The Java commandline argument list is currently sorted alphanumerically in the
admin UI dashboard. If there is any possibility that Java might behave
differently with competing options in a different order (which I think is
likely, but I have not yet verified), it is a bad idea to show them in a
different order than they actually exist on the commandline. In that event, it
would be impossible to determine what Java will actually do if the actual order
cannot be seen.
I propose that we make the list unsorted by default, which will show them in
actual commandline order, and then place some kind of "Sort Args" button/option
on the dashboard that will temporarily order them so it is easier to scan the
list quickly. A page refresh once the list is sorted should restore the
unsorted list.
Additionally, if a separate section showing the actual command could be added
(which would typically show the following), that would be very nice.
Sample of what a section for the actual Java command would contain:
{noformat}
-jar start.jar "--module=http"
{noformat}
was:
Followup issue from discussion on SOLR-11645.
The Java commandline argument list is currently sorted alphanumerically in the
admin UI dashboard. If there is any possibility that Java might behave
differently with competing options in a different order (which I think is
likely, but I have not yet verified), it is a bad idea to show them in a
different order than they actually exist on the commandline. In that event, it
would be impossible to determine what Java will actually do if the actual order
cannot be seen.
I propose that we make the list unsorted by default, which will show them in
actual commandline order, and then place some kind of "Sort Args" button/option
on the dashboard that will temporarily order them so it is easier to scan the
list quickly. A page refresh once the list is sorted should restore the
unsorted list.
> Improve "Args" display in admin UI
> --
>
> Key: SOLR-11649
> URL: https://issues.apache.org/jira/browse/SOLR-11649
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.1
>Reporter: Shawn Heisey
>Priority: Minor
>
> Followup issue from discussion on SOLR-11645.
> The Java commandline argument list is currently sorted alphanumerically in
> the admin UI dashboard. If there is any possibility that Java might behave
> differently with competing options in a different order (which I think is
> likely, but I have not yet verified), it is a bad idea to show them in a
> different order than they actually exist on the commandline. In that event,
> it would be impossible to determine what Java will actually do if the actual
> order cannot be seen.
> I propose that we make the list unsorted by default, which will show them in
> actual commandline order, and then place some kind of "Sort Args"
> button/option on the dashboard that will temporarily order them so it is
> easier to scan the list quickly. A page refresh once the list is sorted
> should restore the unsorted list.
> Additionally, if a separate section showing the actual command could be added
> (which would typically show the following), that would be very nice.
> Sample of what a section for the actual Java command would contain:
> {noformat}
> -jar start.jar "--module=http"
> {noformat}
--
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-11649) Improve "Args" display in admin UI
Shawn Heisey created SOLR-11649: --- Summary: Improve "Args" display in admin UI Key: SOLR-11649 URL: https://issues.apache.org/jira/browse/SOLR-11649 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Affects Versions: 7.1 Reporter: Shawn Heisey Priority: Minor Followup issue from discussion on SOLR-11645. The Java commandline argument list is currently sorted alphanumerically in the admin UI dashboard. If there is any possibility that Java might behave differently with competing options in a different order (which I think is likely, but I have not yet verified), it is a bad idea to show them in a different order than they actually exist on the commandline. In that event, it would be impossible to determine what Java will actually do if the actual order cannot be seen. I propose that we make the list unsorted by default, which will show them in actual commandline order, and then place some kind of "Sort Args" button/option on the dashboard that will temporarily order them so it is easier to scan the list quickly. A page refresh once the list is sorted should restore the unsorted list. -- 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/jdk-9.0.1) - Build # 20925 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20925/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple
Error Message:
Waiting for collection testSimple1 null Live Nodes: [127.0.0.1:32907_solr,
127.0.0.1:36069_solr] Last available state:
DocCollection(testSimple1//collections/testSimple1/state.json/24)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node2":{ "core":"testSimple1_shard1_replica_n1",
"base_url":"https://127.0.0.1:35321/solr;,
"node_name":"127.0.0.1:35321_solr", "state":"down",
"type":"NRT"}, "core_node12":{
"core":"testSimple1_shard1_replica_n11",
"base_url":"https://127.0.0.1:32907/solr;,
"node_name":"127.0.0.1:32907_solr", "state":"active",
"type":"NRT", "leader":"true"}}}, "shard2":{
"range":"0-7fff", "state":"active", "replicas":{
"core_node7":{ "core":"testSimple1_shard2_replica_n4",
"base_url":"https://127.0.0.1:35321/solr;,
"node_name":"127.0.0.1:35321_solr", "state":"down",
"type":"NRT"}, "core_node10":{
"core":"testSimple1_shard2_replica_n9",
"base_url":"https://127.0.0.1:32907/solr;,
"node_name":"127.0.0.1:32907_solr", "state":"active",
"type":"NRT", "leader":"true", "router":{"name":"compositeId"},
"maxShardsPerNode":"2", "autoAddReplicas":"true", "nrtReplicas":"2",
"tlogReplicas":"0"}
Stack Trace:
java.lang.AssertionError: Waiting for collection testSimple1
null
Live Nodes: [127.0.0.1:32907_solr, 127.0.0.1:36069_solr]
Last available state:
DocCollection(testSimple1//collections/testSimple1/state.json/24)={
"pullReplicas":"0",
"replicationFactor":"2",
"shards":{
"shard1":{
"range":"8000-",
"state":"active",
"replicas":{
"core_node2":{
"core":"testSimple1_shard1_replica_n1",
"base_url":"https://127.0.0.1:35321/solr;,
"node_name":"127.0.0.1:35321_solr",
"state":"down",
"type":"NRT"},
"core_node12":{
"core":"testSimple1_shard1_replica_n11",
"base_url":"https://127.0.0.1:32907/solr;,
"node_name":"127.0.0.1:32907_solr",
"state":"active",
"type":"NRT",
"leader":"true"}}},
"shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
"core_node7":{
"core":"testSimple1_shard2_replica_n4",
"base_url":"https://127.0.0.1:35321/solr;,
"node_name":"127.0.0.1:35321_solr",
"state":"down",
"type":"NRT"},
"core_node10":{
"core":"testSimple1_shard2_replica_n9",
"base_url":"https://127.0.0.1:32907/solr;,
"node_name":"127.0.0.1:32907_solr",
"state":"active",
"type":"NRT",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"2",
"autoAddReplicas":"true",
"nrtReplicas":"2",
"tlogReplicas":"0"}
at
__randomizedtesting.SeedInfo.seed([B977DF5669D7F5A:3324590B416EAB8B]: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.AutoAddReplicasIntegrationTest.testSimple(AutoAddReplicasIntegrationTest.java:124)
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
[jira] [Comment Edited] (SOLR-9052) Provide a syntax for Adding Multiple Documents on REST that Uses Proper JSON Format
[
https://issues.apache.org/jira/browse/SOLR-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254894#comment-16254894
]
Mateusz Owdziej edited comment on SOLR-9052 at 11/16/17 8:16 AM:
-
What about accepting json with add key as array and other commands (e.g.
delete). It is difficult (or impossible) to create json with multiple "add"
keys.
Proposition:
{code}
{
"add":{
"doc":[
{
"id":"DOC1",
"my_field":2.3
},
{
"id":"DOC2",
"my_field":4.2
}
]
},
"commit":{ },
"optimize":{ "waitSearcher":false },
"delete":[
{ "id":"ID" },
{ "query":"QUERY" }
]
}{code}
How to make such action using rest api: delete all documents, add new one and
after that commit everything?
was (Author: mateusz.owdziej):
What about accepting json with add key as array and other commands (e.g.
delete). It is difficult (or impossible) to create json with multiply "add"
keys.
Proposition:
{code}
{
"add":{
"doc":[
{
"id":"DOC1",
"my_field":2.3
},
{
"id":"DOC2",
"my_field":4.2
}
]
},
"commit":{ },
"optimize":{ "waitSearcher":false },
"delete":[
{ "id":"ID" },
{ "query":"QUERY" }
]
}{code}
How to make such action using rest api: delete all documents, add new one and
after that commit everything?
> Provide a syntax for Adding Multiple Documents on REST that Uses Proper JSON
> Format
> ---
>
> Key: SOLR-9052
> URL: https://issues.apache.org/jira/browse/SOLR-9052
> Project: Solr
> Issue Type: Improvement
> Components: update
>Reporter: Mary Jo Sminkey
>
> Currently if you want to post a batch of documents to the update handler and
> need to include any options like a boost for each, you have to use a format
> that uses multiple "add" keys, which make it virtually impossible to build an
> object in another language and serialize it since most do not allow multiple
> keys of the same name. Many JSON formatters and validators as well will not
> allow this. While the JSON specs do not exclude it outright, they do say that
> keys "SHOULD" be unique and certainly not having unique keys results in a
> multitude of issues when trying to work with Solr from other languages.
> Please add a way to send multiple documents to the update handler via the
> REST Api that does not require using multiple "add" keys.
--
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
