[JENKINS] Lucene-Solr-8.x-Windows (32bit/jdk1.8.0_172) - Build # 161 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/161/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPISolrJTest.testReadOnlyCollection Error Message: initial num docs expected:<10> but was:<9> Stack Trace: java.lang.AssertionError: initial num docs expected:<10> but was:<9> at __randomizedtesting.SeedInfo.seed([35C48031F5C28D25:1EB672C9BFC19610]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.solr.cloud.CollectionsAPISolrJTest.testReadOnlyCollection(CollectionsAPISolrJTest.java:683) 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:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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 13397 lines...] [junit4] Suite: org.apache.solr.cloud.CollectionsAPISolrJTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr
[jira] [Commented] (SOLR-13333) terms.ttf=true doesn't work when distrib=false and terms.list is not specified
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804616#comment-16804616 ] Munendra S N commented on SOLR-1: - [^SOLR-1.patch] This adds support for terms.ttf=true in case of standalone too. * JSON response format would be handled in SOLR-7530(might need a back incompatible change) * terms.ttf=true is not yet supported for point field. I'm planning to raise separate issue for this. Until that issue is fixed, documentation should mention that. For now, I haven't made documentation changes > terms.ttf=true doesn't work when distrib=false and terms.list is not specified > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Reporter: Munendra S N >Priority: Major > Attachments: SOLR-1.patch > > > In SOLR-10349, support to return total term frequency was added. This works > fine in distributed mode or when terms.list is specified but doesn't work > with non-distributed mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13333) terms.ttf=true doesn't work when distrib=false and terms.list is not specified
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N updated SOLR-1: Attachment: SOLR-1.patch > terms.ttf=true doesn't work when distrib=false and terms.list is not specified > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Reporter: Munendra S N >Priority: Major > Attachments: SOLR-1.patch > > > In SOLR-10349, support to return total term frequency was added. This works > fine in distributed mode or when terms.list is specified but doesn't work > with non-distributed mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] Release Lucene/Solr 6.6.6 RC1
Please vote for release candidate 1 for Lucene/Solr 6.6.6The artifacts can be downloaded from:https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.6-RC1-rev68fa249034ba8b273955f20097700dc2fbb7a800 You can run the smoke tester directly with this command:python3 -u dev-tools/scripts/smokeTestRelease.py \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.6-RC1-rev68fa249034ba8b273955f20097700dc2fbb7a800Here's my +1 SUCCESS! [0:45:48.015409]
[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 56 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/56/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsChaosMonkeyNothingIsSafeTest Error Message: ObjectTracker found 3 object(s) that were not released!!! [NRTCachingDirectory, InternalHttpClient, SolrCore] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.NRTCachingDirectory at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199) at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:744) at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:165) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:502) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) at org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.http.impl.client.InternalHttpClient at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321) at org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330) at org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:230) at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:272) at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:420) at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:237) at org.apache.solr.cloud.RecoveryStrategy.doSyncOrReplicateRecovery(RecoveryStrategy.java:652) at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:326) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:307) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCA
[JENKINS] Lucene-Solr-repro - Build # 3083 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3083/ [...truncated 29 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1292/consoleText [repro] Revision: 90d983cf7cd8bf867a16fe8916b523d52d72b439 [repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 [repro] Repro line: ant test -Dtestcase=MetricTriggerIntegrationTest -Dtests.method=testMetricTrigger -Dtests.seed=459FF9398BDDC80C -Dtests.multiplier=2 -Dtests.locale=vi -Dtests.timezone=Europe/Paris -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: b2941ff0da4987dec4774aa6b4bb7c597b362243 [repro] git fetch [repro] git checkout 90d983cf7cd8bf867a16fe8916b523d52d72b439 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] MetricTriggerIntegrationTest [repro] ant compile-test [...truncated 3564 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.MetricTriggerIntegrationTest" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=459FF9398BDDC80C -Dtests.multiplier=2 -Dtests.locale=vi -Dtests.timezone=Europe/Paris -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 2640 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 2/5 failed: org.apache.solr.cloud.autoscaling.MetricTriggerIntegrationTest [repro] git checkout b2941ff0da4987dec4774aa6b4bb7c597b362243 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11) - Build # 318 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/318/ Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.index.UninvertDocValuesMergePolicyTest.testIndexAndAddDocValues Error Message: expected:<[7]> but was:<[98]> Stack Trace: org.junit.ComparisonFailure: expected:<[7]> but was:<[98]> at __randomizedtesting.SeedInfo.seed([FD07CB6CB0AFCB8D:A8E04DAFF9488B79]:0) at org.junit.Assert.assertEquals(Assert.java:115) at org.junit.Assert.assertEquals(Assert.java:144) at org.apache.solr.index.UninvertDocValuesMergePolicyTest.lambda$testIndexAndAddDocValues$2(UninvertDocValuesMergePolicyTest.java:143) at org.apache.solr.index.UninvertDocValuesMergePolicyTest.withNewRawReader(UninvertDocValuesMergePolicyTest.java:233) at org.apache.solr.index.UninvertDocValuesMergePolicyTest.testIndexAndAddDocValues(UninvertDocValuesMergePolicyTest.java:118) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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(Thr
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-12) - Build # 160 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/160/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.security.JWTAuthPluginIntegrationTest.testMetrics Error Message: Server returned HTTP response code: 401 for URL: http://127.0.0.1:60719/solr/jwtColl/query?q=*:* Stack Trace: java.io.IOException: Server returned HTTP response code: 401 for URL: http://127.0.0.1:60719/solr/jwtColl/query?q=*:* at __randomizedtesting.SeedInfo.seed([EDC61106A1B8F052:13D4C3A4BDB287E1]:0) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1913) at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) at java.base/java.net.URLConnection.getContent(URLConnection.java:749) at org.apache.solr.security.JWTAuthPluginIntegrationTest.get(JWTAuthPluginIntegrationTest.java:207) at org.apache.solr.security.JWTAuthPluginIntegrationTest.testMetrics(JWTAuthPluginIntegrationTest.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:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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.Thr
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 23837 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23837/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=787, name=testExecutor-157-thread-3, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=787, name=testExecutor-157-thread-3, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at __randomizedtesting.SeedInfo.seed([250F48BA3FFFBEA8:AD5B77609103D350]:0) Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:46511/_a/e: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([250F48BA3FFFBEA8]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649) 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.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$1(BasicDistributedZkTest.java:656) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=1790, name=testExecutor-418-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=1790, name=testExecutor-418-thread-1, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] at __randomizedtesting.SeedInfo.seed([250F48BA3FFFBEA8:AD5B77609103D350]:0) Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35173/_a/e: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([250F48BA3FFFBEA8]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649) 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.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$1(BasicDistributedZkTest.java:656) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=11680, name=testExecutor-2616-thread-2, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=11680, name=testExecutor-2616-thread-2, state=RUNNABLE, group=TGRP-BasicDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:42239/_a/e: ADDREPLICA failed to create replica at __randomizedtesting.SeedInfo.seed([250F48BA3FFFBEA8]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649) 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.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$1(BasicDistributedZkTest.java:656) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
[jira] [Resolved] (SOLR-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-13349.
---
Resolution: Fixed
Fix Version/s: master (9.0)
8.1
7.7.2
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13349.patch
>
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804426#comment-16804426
]
Erick Erickson commented on SOLR-13349:
---
[~ichattopadhyaya] I take it back, I put the entries in CHANGES.txt for both 7x
and 7.7.2, so you should be good to go.
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804424#comment-16804424
]
ASF subversion and git services commented on SOLR-13349:
Commit 9e1ada0ab72f3a41104b422ebd03665528b7d2ab in lucene-solr's branch
refs/heads/branch_7_7 from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9e1ada0 ]
SOLR-13349: High CPU usage in Solr due to Java 8 bug
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3233 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3233/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudHttp2SolrClientTest Error Message: ObjectTracker found 10 object(s) that were not released!!! [SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, InternalHttpClient, MockDirectoryWrapper] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.core.SolrCore at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.SolrCore.(SolrCore.java:1063) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:368) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:747) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.Objec
[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804409#comment-16804409
]
ASF subversion and git services commented on SOLR-13349:
Commit 8773e6b160029b43764c4b9459efe9624c52cb31 in lucene-solr's branch
refs/heads/branch_7x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8773e6b ]
SOLR-13349:High CPU usage in Solr due to Java 8 bug
(cherry picked from commit b2941ff)
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804410#comment-16804410
]
ASF subversion and git services commented on SOLR-13349:
Commit 7dfe1c093b65f77407c2df4c2a1120a213aef166 in lucene-solr's branch
refs/heads/branch_7x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7dfe1c0 ]
SOLR-13349: High CPU usage in Solr due to Java 8 bug
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1292 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1292/ No tests ran. Build Log: [...truncated 23440 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 25: list item index: expected 2, got 1 [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 26: list item index: expected 3, got 1 [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 224: list item index: expected 2, got 1 [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 225: list item index: expected 3, got 1 [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 25: list item index: expected 2, got 1 [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 26: list item index: expected 3, got 1 [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 224: list item index: expected 2, got 1 [asciidoctor:convert] asciidoctor: WARNING: aliases.adoc: line 225: list item index: expected 3, got 1 [java] Processed 2516 links (2061 relative) to 3334 anchors in 252 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-
[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804395#comment-16804395
]
ASF subversion and git services commented on SOLR-13349:
Commit 03a3562f782a795afb3e5dbb474aca216273cc4d in lucene-solr's branch
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=03a3562 ]
SOLR-13349:High CPU usage in Solr due to Java 8 bug
(cherry picked from commit b2941ff)
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13349) High CPU usage in Solr due to Java 8 bug
[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804390#comment-16804390
]
ASF subversion and git services commented on SOLR-13349:
Commit b2941ff0da4987dec4774aa6b4bb7c597b362243 in lucene-solr's branch
refs/heads/master from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b2941ff ]
SOLR-13349:High CPU usage in Solr due to Java 8 bug
> High CPU usage in Solr due to Java 8 bug
>
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13353) Add SolrCli AuthTool test
[ https://issues.apache.org/jira/browse/SOLR-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804380#comment-16804380 ] ASF subversion and git services commented on SOLR-13353: Commit e99fd063b05200e8ce64fa6594fc94bfdefb77c1 in lucene-solr's branch refs/heads/branch_8x from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e99fd06 ] SOLR-13353: Add SolrCli AuthTool test Signed-off-by: Kevin Risden > Add SolrCli AuthTool test > - > > Key: SOLR-13353 > URL: https://issues.apache.org/jira/browse/SOLR-13353 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13353.patch > > Time Spent: 40m > Remaining Estimate: 0h > > [~janhoy] pointed out on SOLR-9079 that it broke SolrCli AuthTool. There are > no tests for the AuthTool currently so while fixing added a simple test to > make sure we don't break it again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13353) Add SolrCli AuthTool test
[ https://issues.apache.org/jira/browse/SOLR-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804379#comment-16804379 ] ASF subversion and git services commented on SOLR-13353: Commit 8d658a8cfb8d4ba1f314c2ebf493443dafd34639 in lucene-solr's branch refs/heads/master from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8d658a8 ] SOLR-13353: Add SolrCli AuthTool test Signed-off-by: Kevin Risden > Add SolrCli AuthTool test > - > > Key: SOLR-13353 > URL: https://issues.apache.org/jira/browse/SOLR-13353 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13353.patch > > Time Spent: 40m > Remaining Estimate: 0h > > [~janhoy] pointed out on SOLR-9079 that it broke SolrCli AuthTool. There are > no tests for the AuthTool currently so while fixing added a simple test to > make sure we don't break it again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] risdenk merged pull request #626: SOLR-13353: Add SolrCli AuthTool test
risdenk merged pull request #626: SOLR-13353: Add SolrCli AuthTool test URL: https://github.com/apache/lucene-solr/pull/626 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804351#comment-16804351
]
Jan Høydahl commented on SOLR-12860:
Ok. [~yael.lorenzo] perhaps you want to give it a shot, to add the same MDC
stuff to the patch as is done for the other pools, with proper unsetting the
flag?
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Attachments: SOLR-12860.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_112]
> at
>
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7845 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7845/ Java: 32bit/jdk1.8.0_172 -client -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest Error Message: ObjectTracker found 5 object(s) that were not released!!! [MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509) at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:422) at org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1191) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:368) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:747) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348) at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:99) at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:779) at org.apache.solr.core.SolrCore.(SolrCore.java:976) at org.apache.solr.core.SolrCore.(SolrCore.java:883) at org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1193) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1103) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396) at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.lucene.store.MockDirectoryWrapper at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.CachingDire
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804344#comment-16804344
]
Noble Paul commented on SOLR-12860:
---
MDC may not be required for the trans if it's not logging anything in that
thread. But how can we be sure about it.? It's much better to just use the
standard thread pool instead of rolling your own
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Attachments: SOLR-12860.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.
[GitHub] [lucene-solr] janhoy commented on a change in pull request #626: SOLR-13353: Add SolrCli AuthTool test
janhoy commented on a change in pull request #626: SOLR-13353: Add SolrCli
AuthTool test
URL: https://github.com/apache/lucene-solr/pull/626#discussion_r270215682
##
File path: solr/core/src/test/org/apache/solr/util/AuthToolTest.java
##
@@ -0,0 +1,76 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.util;
+
+import java.nio.file.Files;
+import java.nio.file.Path;
+
+import org.apache.commons.cli.CommandLine;
+import org.apache.solr.cloud.SolrCloudTestCase;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+import static org.apache.solr.util.SolrCLI.findTool;
+import static org.apache.solr.util.SolrCLI.parseCmdLine;
+
+/**
+ * Unit test for SolrCLI's AuthTool
+ */
+public class AuthToolTest extends SolrCloudTestCase {
+ private Path dir;
+
+ @BeforeClass
+ public static void setupCluster() throws Exception {
+configureCluster(1)
+.addConfig("config",
TEST_PATH().resolve("configsets").resolve("cloud-minimal").resolve("conf"))
+.configure();
+ }
+
+ @Before
+ public void setUp() throws Exception {
+super.setUp();
+dir = createTempDir("AuthToolTest").toAbsolutePath();
+ }
+
+ @After
+ public void tearDown() throws Exception {
+super.tearDown();
+org.apache.commons.io.FileUtils.deleteDirectory(dir.toFile());
+ }
+
+ @Test
+ public void testEnableAuth() throws Exception {
+Path solrIncludeFile =
Files.createFile(dir.resolve("solrIncludeFile.txt"));
Review comment:
That's ok
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804337#comment-16804337
]
Jan Høydahl commented on SOLR-12860:
What is this whole MDC thing, do we need it for the scheduled tasks? And will
it work ok to just set the flag on the thread when execute() starts, and not
bother to clear it? Will that thread be re-used again somewhere else later
where it would matter? Tried to keep it short.
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Attachments: SOLR-12860.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.Schedul
[jira] [Commented] (LUCENE-6968) LSH Filter
[
https://issues.apache.org/jira/browse/LUCENE-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804310#comment-16804310
]
Andy Hind commented on LUCENE-6968:
---
[~mayyas], in answer to your questions:
1) Depends on your view - a lower default would probably make sense. The
default of 512 is good for 3-10+ pages of A4 text - again with an "it
depends" caveat
2) Query time is covered here https://issues.apache.org/jira/browse/SOLR-12879
You can probably get away with the default query time tokenisation in SOLR,
post BM25.
> LSH Filter
> --
>
> Key: LUCENE-6968
> URL: https://issues.apache.org/jira/browse/LUCENE-6968
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Cao Manh Dat
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 6.2, 7.0
>
> Attachments: LUCENE-6968.4.patch, LUCENE-6968.5.patch,
> LUCENE-6968.6.patch, LUCENE-6968.patch, LUCENE-6968.patch, LUCENE-6968.patch
>
>
> I'm planning to implement LSH. Which support query like this
> {quote}
> Find similar documents that have 0.8 or higher similar score with a given
> document. Similarity measurement can be cosine, jaccard, euclid..
> {quote}
> For example. Given following corpus
> {quote}
> 1. Solr is an open source search engine based on Lucene
> 2. Solr is an open source enterprise search engine based on Lucene
> 3. Solr is an popular open source enterprise search engine based on Lucene
> 4. Apache Lucene is a high-performance, full-featured text search engine
> library written entirely in Java
> {quote}
> We wanna find documents that have 0.6 score in jaccard measurement with this
> doc
> {quote}
> Solr is an open source search engine
> {quote}
> It will return only docs 1,2 and 3 (MoreLikeThis will also return doc 4)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] risdenk commented on a change in pull request #626: SOLR-13353: Add SolrCli AuthTool test
risdenk commented on a change in pull request #626: SOLR-13353: Add SolrCli
AuthTool test
URL: https://github.com/apache/lucene-solr/pull/626#discussion_r270202711
##
File path: solr/core/src/test/org/apache/solr/util/AuthToolTest.java
##
@@ -0,0 +1,76 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.util;
+
+import java.nio.file.Files;
+import java.nio.file.Path;
+
+import org.apache.commons.cli.CommandLine;
+import org.apache.solr.cloud.SolrCloudTestCase;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+import static org.apache.solr.util.SolrCLI.findTool;
+import static org.apache.solr.util.SolrCLI.parseCmdLine;
+
+/**
+ * Unit test for SolrCLI's AuthTool
+ */
+public class AuthToolTest extends SolrCloudTestCase {
+ private Path dir;
+
+ @BeforeClass
+ public static void setupCluster() throws Exception {
+configureCluster(1)
+.addConfig("config",
TEST_PATH().resolve("configsets").resolve("cloud-minimal").resolve("conf"))
+.configure();
+ }
+
+ @Before
+ public void setUp() throws Exception {
+super.setUp();
+dir = createTempDir("AuthToolTest").toAbsolutePath();
+ }
+
+ @After
+ public void tearDown() throws Exception {
+super.tearDown();
+org.apache.commons.io.FileUtils.deleteDirectory(dir.toFile());
+ }
+
+ @Test
+ public void testEnableAuth() throws Exception {
+Path solrIncludeFile =
Files.createFile(dir.resolve("solrIncludeFile.txt"));
Review comment:
Yea I took the same pattern from `UtilsToolTest`. I figured someone will
come along and want to add more tests to AuthToolTest and need the directory
created.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #626: SOLR-13353: Add SolrCli AuthTool test
janhoy commented on a change in pull request #626: SOLR-13353: Add SolrCli
AuthTool test
URL: https://github.com/apache/lucene-solr/pull/626#discussion_r270200579
##
File path: solr/core/src/test/org/apache/solr/util/AuthToolTest.java
##
@@ -0,0 +1,76 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.util;
+
+import java.nio.file.Files;
+import java.nio.file.Path;
+
+import org.apache.commons.cli.CommandLine;
+import org.apache.solr.cloud.SolrCloudTestCase;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+import static org.apache.solr.util.SolrCLI.findTool;
+import static org.apache.solr.util.SolrCLI.parseCmdLine;
+
+/**
+ * Unit test for SolrCLI's AuthTool
+ */
+public class AuthToolTest extends SolrCloudTestCase {
+ private Path dir;
+
+ @BeforeClass
+ public static void setupCluster() throws Exception {
+configureCluster(1)
+.addConfig("config",
TEST_PATH().resolve("configsets").resolve("cloud-minimal").resolve("conf"))
+.configure();
+ }
+
+ @Before
+ public void setUp() throws Exception {
+super.setUp();
+dir = createTempDir("AuthToolTest").toAbsolutePath();
+ }
+
+ @After
+ public void tearDown() throws Exception {
+super.tearDown();
+org.apache.commons.io.FileUtils.deleteDirectory(dir.toFile());
+ }
+
+ @Test
+ public void testEnableAuth() throws Exception {
+Path solrIncludeFile =
Files.createFile(dir.resolve("solrIncludeFile.txt"));
Review comment:
You could skip the setup() and tearDown() and instead create the tmpdir in
the test method. No need to delete it, it should be deleted automatically on
test suite termination.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12879) Query Parser for MinHash/LSH
[ https://issues.apache.org/jira/browse/SOLR-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804303#comment-16804303 ] Andy Hind commented on SOLR-12879: -- I do not see the docs for this updated/added in 8.0 ... > Query Parser for MinHash/LSH > > > Key: SOLR-12879 > URL: https://issues.apache.org/jira/browse/SOLR-12879 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.0 >Reporter: Andy Hind >Assignee: Tommaso Teofili >Priority: Major > Fix For: 8.0 > > Attachments: minhash.filter.adoc.fragment, minhash.patch, > minhash.qparser.adoc.fragment > > > Following on from https://issues.apache.org/jira/browse/LUCENE-6968, provide > a query parser that builds queries that provide a measure of Jaccard > similarity. The initial patch includes banded queries that were also proposed > on the original issue. > > I have one outstanding questions: > * Should the score from the overall query be normalised? > Note, that the band count is currently approximate and may be one less than > in practise. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8726) WrappedDoubleValuesSource can leak IndexSearcher references
[ https://issues.apache.org/jira/browse/LUCENE-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804257#comment-16804257 ] Cassandra Targett commented on LUCENE-8726: --- [~romseygeek], I know a user who ran into this with Solr 7.5, and it occurred to me others might hit it too. Would it be possible to backport this into branch_7_7 so we could release it with the next bug fix release of Lucene & Solr 7.7.x that we do? > WrappedDoubleValuesSource can leak IndexSearcher references > --- > > Key: LUCENE-8726 > URL: https://issues.apache.org/jira/browse/LUCENE-8726 > Project: Lucene - Core > Issue Type: Bug >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 8.1 > > Attachments: LUCENE-8726.patch > > > Cause of SOLR-13315 > Index-specific DoubleValuesSources can be created by > DoubleValuesSource.rewrite(), and the various consumers of these sources are > careful not to store these rewritten sources on long-lived objects, such as > queries that may be re-used between searchers. However, the bridge code > between ValueSource and DoubleValuesSource does not return a new object from > its rewrite method, instead caching the passed-in IndexSearcher, which means > references to this searcher may leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804255#comment-16804255
]
Noble Paul commented on SOLR-12860:
---
This is the correct fix [~janhoy] .
{{Executors.newScheduledThreadPool}} should be a forbidden API. Only Solr
Threads can propagate the proper credentials
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Attachments: SOLR-12860.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_112]
> at
> java.
Solr/Java version
I’ve done what I think are the final edits to: https://wiki.apache.org/solr/SolrJavaVersions I spent some time today culling through the JIRAs that mentioned various Java versions. I’m making the leap that SSL/http2 issues are OK in 8x: SOLR-12988 SOLR-12990 SOLR-13048 I guess that http2 can be spoofed at worst by falling back to http1, but what about SSL? And especially with, say, Java 11 and 7x? I’ve included warnings in the page about testing in the local environment when one or both is being used. Next steps: 1> unless there are objections/modifications, I’ll move this over to the website sometime this weekend/early next week. 2> I’ll add a link in the reference guide to that page rather than try to incorporate it in the ref guide. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 317 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/317/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.DistribCursorPagingTest.test Error Message: nextCursorMark is null/missing Stack Trace: java.lang.AssertionError: nextCursorMark is null/missing at __randomizedtesting.SeedInfo.seed([7AEB37F8AD10E7BB:F2BF082203EC8A43]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertNotNull(Assert.java:712) at org.apache.solr.cloud.DistribCursorPagingTest.assertHashNextCursorMark(DistribCursorPagingTest.java:687) at org.apache.solr.cloud.DistribCursorPagingTest.assertFullWalkNoDups(DistribCursorPagingTest.java:722) at org.apache.solr.cloud.DistribCursorPagingTest.doRandomSortsOnLargeIndex(DistribCursorPagingTest.java:596) at org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:94) 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:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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)
[jira] [Commented] (SOLR-12120) New plugin type AuditLoggerPlugin
[
https://issues.apache.org/jira/browse/SOLR-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804226#comment-16804226
]
Jan Høydahl commented on SOLR-12120:
New in last few commits:
* Add {{muteRules}} config param for muting certain requests, collections,
users, ip etc …
* New RequestType enum ADMIN, SEARCH, UPDATE, STREAMING, UNKNOWN always
filled, using URL matching if necessary
* New event field {{requestUrl}} containing full URL from request
* Add unit and integration tests
* Change field {{solrParams}} into {{Map>}}, fix
solrParams related bug
Getting closer to committable
> New plugin type AuditLoggerPlugin
> -
>
> Key: SOLR-12120
> URL: https://issues.apache.org/jira/browse/SOLR-12120
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Solr needs a well defined plugin point to implement audit logging
> functionality, which is independent from whatever {{AuthenticationPlugin}} or
> {{AuthorizationPlugin}} are in use at the time.
> It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It
> could be configured in solr.xml or it could be a third type of plugin defined
> in {{security.json}}, i.e.
> {code:java}
> {
> "authentication" : { "class" : ... },
> "authorization" : { "class" : ... },
> "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
> }
> {code}
> We could then instrument SolrDispatchFilter to the audit plugin with an
> AuditEvent at important points such as successful authentication:
> {code:java}
> auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED,
> request));
> {code}
> We will mark the impl as {{@lucene.experimental}} in the first release to
> let it settle as people write their own plugin implementations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 88 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/88/ 2 tests failed. FAILED: org.apache.solr.cloud.TestCloudSearcherWarming.testRepFactor1LeaderStartup Error Message: No live SolrServers available to handle this request Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:343) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1055) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:830) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:763) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224) at org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547) at org.apache.solr.cloud.TestCloudSearcherWarming.tearDown(TestCloudSearcherWarming.java:78) 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:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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.T
Re: Stop testing with Java 9 or 10?
In my opinion, we should test all versions between the minimum required version and the greatest version at the time of a release. So my preference would be to keep testing on Java 8 and 9, possibly less frequently. On Thu, Mar 28, 2019 at 7:51 PM Erick Erickson wrote: > > What do people think about stoping testing 8.x with Java 9 or 10? Master will > soon have a minimal version of 11, so that’s a moot point. > > I’m wondering if there’s much utility there. I note that some of the Java > supplier don’t bother with either of those versions. Then the resources could > be freed up for 12, 13 etc. > > Occurred to me while trying to get my arms around the whole “what version of > Java/Solr are tested” question. > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #613: LUCENE-8671: Expose FST off/on-heap options on Lucene50PostingsFormat
mikemccand commented on a change in pull request #613: LUCENE-8671: Expose FST
off/on-heap options on Lucene50PostingsFormat
URL: https://github.com/apache/lucene-solr/pull/613#discussion_r270152799
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/blocktree/FieldReader.java
##
@@ -84,21 +85,18 @@
// if (DEBUG) {
// System.out.println("BTTR: seg=" + segment + " field=" +
fieldInfo.name + " rootBlockCode=" + rootCode + " divisor=" + indexDivisor);
// }
-
rootBlockFP = (new ByteArrayDataInput(rootCode.bytes, rootCode.offset,
rootCode.length)).readVLong() >>> BlockTreeTermsReader.OUTPUT_FLAGS_NUM_BITS;
-
+// Initialize FST offheap if index is MMapDirectory and
+// docCount != sumDocFreq implying field is not primary key
+isFSTOffHeap = ((this.docCount != this.sumDocFreq) || openedFromWriter ==
false) && loadFSTOffHeap;
Review comment:
Should we instead pass in the `FSTLoadMode` enum down here? And if it's
AUTO then apply these defaulting heuristics?
This way the codec/caller could decide to leave FST off heap even if its a
primary key field or its opened from writer?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Stop testing with Java 9 or 10?
What do people think about stoping testing 8.x with Java 9 or 10? Master will soon have a minimal version of 11, so that’s a moot point. I’m wondering if there’s much utility there. I note that some of the Java supplier don’t bother with either of those versions. Then the resources could be freed up for 12, 13 etc. Occurred to me while trying to get my arms around the whole “what version of Java/Solr are tested” question. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12990) High test failure rate on Java11/12 when (randomized) ssl=true clientAuth=false
[
https://issues.apache.org/jira/browse/SOLR-12990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804189#comment-16804189
]
Hoss Man commented on SOLR-12990:
-
the issues are related but not dups -- that issue was a reliably failure in a
particular situattion regarding checkPeerName, this issue was about hard to
reproduce failures that only happened when clientAuth=false but SSL was in ue.
I have no idea if it can be closed, i haven't audit recent java11 jenkins
failures looking for the same hard to reproduce failures.
> High test failure rate on Java11/12 when (randomized) ssl=true
> clientAuth=false
> ---
>
> Key: SOLR-12990
> URL: https://issues.apache.org/jira/browse/SOLR-12990
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Labels: Java11, Java12
> Attachments: DistributedDebugComponentTest.ssl.debug.log.txt,
> enable.ssl.debug.patch
>
>
> Ever since the policeman's Jenkins instance started running tests on Java11,
> we've seen an abnormally high number of test failures that seem to be related
> to randomzed ssl.
> I've been investigating these logs, and trying to reproduce and have found
> the following observations:
> * In all the policeman jenkins logs i looked at, these SSL related failures
> only occur when the RandomizeSSL annotation picks {{ssl=true
> clientAuth=false}}
> ** NOTE: this doesn't mean that every test using {{ssl=true
> clientAuth=false}} failed -- since our build system only prints test output
> when tests fail, it's possible/probably (based on how often the value should
> be picked) that many tests randomly use {{ssl=true clientAuth=false}} and pass
> * the failures usually showed an exception that was {{Caused by:
> javax.net.ssl.SSLException: Received fatal alert: internal_error}} in the
> logs.
> * when i attempted to re-produce some of these failing seeds on my own
> machine using Java11, i could not _reliably_ reproduce these failures w/the
> same seeds
> ** beasting could _occasionally_ reproduce the failures, at roughly 1/10 runs
> ** suggesting that system load/timing contributed to these SSL related
> failures
> * picking one particularly trivial test (DistributedDebugComponentTest)
> ** with {{javax.net.debug=all}} enabled, i was able to see more details...
> *** notably: {{Fatal (INTERNAL_ERROR): Session has no PSK}}
> ** when I patched the test to force {{ssl=true clientAuth=true}} I was unable
> to trigger any failures with the same seed.
> * on the jira/http2 branch I was unable to reproduce these failures at all,
> w/o any patching
> ** similar to SOLR-12988, this may be because of bug fixes in the upgraded
> jetty.
>
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8740) AssertionError FlattenGraphFilter
[ https://issues.apache.org/jira/browse/LUCENE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804188#comment-16804188 ] Michael McCandless commented on LUCENE-8740: Maybe a dup of https://issues.apache.org/jira/browse/LUCENE-8723? > AssertionError FlattenGraphFilter > - > > Key: LUCENE-8740 > URL: https://issues.apache.org/jira/browse/LUCENE-8740 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.5, 8.0 >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8740.patch > > > Our unit tests picked up an unusual AssertionError in FlattenGraphFilter > which manifests itself only in very specific circumstances involving > WordDelimiterGraph, StopFilter, FlattenGraphFilter and MinhashFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on java11: "SSLPeerUnverifiedException: peer not authenticated"
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804186#comment-16804186
]
Hoss Man commented on SOLR-12988:
-
there are still tests disabled due to this isue, so it can't really be resolved
until they are vetted to work correctly on java11 and higher...
{noformat}
$ find -name \*.java | xargs grep SOLR-12988
./src/test/org/apache/solr/cloud/TestSSLRandomization.java:
assumeFalse("@AwaitsFix: SOLR-12988 - ssl issues on Java 11/12",
Constants.JRE_IS_MINIMUM_JAVA11);
./src/test/org/apache/solr/cloud/TestMiniSolrCloudClusterSSL.java:
assumeFalse("@AwaitsFix: SOLR-12988 - ssl issues on Java 11/12",
Constants.JRE_IS_MINIMUM_JAVA11);
{noformat}
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on
> java11: "SSLPeerUnverifiedException: peer not authenticated"
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
>
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4012) LeaderIntegrationTest sometimes hangs
[ https://issues.apache.org/jira/browse/SOLR-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804169#comment-16804169 ] Erick Erickson commented on SOLR-4012: -- Can we close this? > LeaderIntegrationTest sometimes hangs > - > > Key: SOLR-4012 > URL: https://issues.apache.org/jira/browse/SOLR-4012 > Project: Solr > Issue Type: Test > Components: Tests > Environment: windows >Reporter: Robert Muir >Priority: Major > > I was unable to get a stacktrace before. This time I succeeded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8732) Allow ConstantScoreQuery to skip counting hits
[ https://issues.apache.org/jira/browse/LUCENE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804163#comment-16804163 ] Adrien Grand commented on LUCENE-8732: -- If someone has time to look, I think we have a similar issue with boolean queries that only consist of filter clauses. > Allow ConstantScoreQuery to skip counting hits > -- > > Key: LUCENE-8732 > URL: https://issues.apache.org/jira/browse/LUCENE-8732 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jim Ferenczi >Priority: Minor > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8732.patch > > > We already have a ConstantScoreScorer that knows how to early terminate the > collection but the ConstantScoreQuery uses a private scorer that doesn't take > advantage of setMinCompetitiveScore. This issue is about reusing the > ConstantScoreScorer in the ConstantScoreQuery in order to early terminate > queries that don't need to compute the total number of hits. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12990) High test failure rate on Java11/12 when (randomized) ssl=true clientAuth=false
[
https://issues.apache.org/jira/browse/SOLR-12990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804162#comment-16804162
]
Erick Erickson commented on SOLR-12990:
---
Dup of SOLR-12988? And can it be closed?
[~hossman] [~caomanhdat] ^^
> High test failure rate on Java11/12 when (randomized) ssl=true
> clientAuth=false
> ---
>
> Key: SOLR-12990
> URL: https://issues.apache.org/jira/browse/SOLR-12990
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Labels: Java11, Java12
> Attachments: DistributedDebugComponentTest.ssl.debug.log.txt,
> enable.ssl.debug.patch
>
>
> Ever since the policeman's Jenkins instance started running tests on Java11,
> we've seen an abnormally high number of test failures that seem to be related
> to randomzed ssl.
> I've been investigating these logs, and trying to reproduce and have found
> the following observations:
> * In all the policeman jenkins logs i looked at, these SSL related failures
> only occur when the RandomizeSSL annotation picks {{ssl=true
> clientAuth=false}}
> ** NOTE: this doesn't mean that every test using {{ssl=true
> clientAuth=false}} failed -- since our build system only prints test output
> when tests fail, it's possible/probably (based on how often the value should
> be picked) that many tests randomly use {{ssl=true clientAuth=false}} and pass
> * the failures usually showed an exception that was {{Caused by:
> javax.net.ssl.SSLException: Received fatal alert: internal_error}} in the
> logs.
> * when i attempted to re-produce some of these failing seeds on my own
> machine using Java11, i could not _reliably_ reproduce these failures w/the
> same seeds
> ** beasting could _occasionally_ reproduce the failures, at roughly 1/10 runs
> ** suggesting that system load/timing contributed to these SSL related
> failures
> * picking one particularly trivial test (DistributedDebugComponentTest)
> ** with {{javax.net.debug=all}} enabled, i was able to see more details...
> *** notably: {{Fatal (INTERNAL_ERROR): Session has no PSK}}
> ** when I patched the test to force {{ssl=true clientAuth=true}} I was unable
> to trigger any failures with the same seed.
> * on the jira/http2 branch I was unable to reproduce these failures at all,
> w/o any patching
> ** similar to SOLR-12988, this may be because of bug fixes in the upgraded
> jetty.
>
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13353) Add SolrCli AuthTool test
[ https://issues.apache.org/jira/browse/SOLR-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804161#comment-16804161 ] Kevin Risden commented on SOLR-13353: - The new test fails before reverting the change that was made in SOLR-9079 that broke AuthTool. Test passes with proper boolean handling. > Add SolrCli AuthTool test > - > > Key: SOLR-13353 > URL: https://issues.apache.org/jira/browse/SOLR-13353 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13353.patch > > Time Spent: 10m > Remaining Estimate: 0h > > [~janhoy] pointed out on SOLR-9079 that it broke SolrCli AuthTool. There are > no tests for the AuthTool currently so while fixing added a simple test to > make sure we don't break it again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13353) Add SolrCli AuthTool test
[ https://issues.apache.org/jira/browse/SOLR-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13353: Attachment: SOLR-13353.patch > Add SolrCli AuthTool test > - > > Key: SOLR-13353 > URL: https://issues.apache.org/jira/browse/SOLR-13353 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13353.patch > > > [~janhoy] pointed out on SOLR-9079 that it broke SolrCli AuthTool. There are > no tests for the AuthTool currently so while fixing added a simple test to > make sure we don't break it again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] risdenk opened a new pull request #626: SOLR-13353: Add SolrCli AuthTool test
risdenk opened a new pull request #626: SOLR-13353: Add SolrCli AuthTool test URL: https://github.com/apache/lucene-solr/pull/626 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12988) TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on java11: "SSLPeerUnverifiedException: peer not authenticated"
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804158#comment-16804158
]
Erick Erickson commented on SOLR-12988:
---
[~hossman] [~caomanhdat] Can this be closed now that the HTTP2 branch has been
merged?
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName fails reliably on
> java11: "SSLPeerUnverifiedException: peer not authenticated"
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12
>
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of
> the time when run with java11 (or java12), regardless of seed, on both master
> & 7x.
> The nature of the problem and the way our htp stack works suggests it *may*
> ultimately be a jetty bug (perhaps related to [jetty
> issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have
> been fixed on the {{jira/http2}} branch (as of
> 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting
> merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to
> use it for discussions/considerations of other backports/fixes to 7x
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12894) Solr documention for Java Vendors
[
https://issues.apache.org/jira/browse/SOLR-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-12894:
-
Assignee: Erick Erickson
> Solr documention for Java Vendors
> -
>
> Key: SOLR-12894
> URL: https://issues.apache.org/jira/browse/SOLR-12894
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Varun Thacker
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12894.patch, SOLR-12894.patch
>
>
> I was asked a question recently - "Is using OpenJDK safe with Solr 7.4" . To
> which my answer was yes . This was after I checked with Steve on which
> OpenJDK version runs on his jenkins
> For refrerence it currently uses -
> {code:java}
> openjdk version "1.8.0_171"
> OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-1~bpo8+1-b11)
> OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode){code}
>
> Solr's ref guide (
> [https://lucene.apache.org/solr/guide/installing-solr.html#got-java|https://lucene.apache.org/solr/guide/6_6/installing-solr.html#got-java]
> ) mentions using Oracle 1.8 or higher .
>
> We should mention that both Oracle JDKs and Open JDKs are tested. Perhaps
> even have a compatibility matrix
>
> Also we should note that Java 9 and 10 are short term releases . Hence remove
> wording that using Java8+ with more spefic versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13353) Add SolrCli AuthTool test
[ https://issues.apache.org/jira/browse/SOLR-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13353: Issue Type: Test (was: Bug) > Add SolrCli AuthTool test > - > > Key: SOLR-13353 > URL: https://issues.apache.org/jira/browse/SOLR-13353 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 8.1, master (9.0) > > > [~janhoy] pointed out on SOLR-9079 that it broke SolrCli AuthTool. There are > no tests for the AuthTool currently so while fixing added a simple test to > make sure we don't break it again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13353) Add SolrCli AuthTool test
Kevin Risden created SOLR-13353: --- Summary: Add SolrCli AuthTool test Key: SOLR-13353 URL: https://issues.apache.org/jira/browse/SOLR-13353 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Kevin Risden Assignee: Kevin Risden Fix For: 8.1, master (9.0) [~janhoy] pointed out on SOLR-9079 that it broke SolrCli AuthTool. There are no tests for the AuthTool currently so while fixing added a simple test to make sure we don't break it again. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency
[ https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804155#comment-16804155 ] Kevin Risden commented on SOLR-9079: [~janhoy] going to fix as part of SOLR-13353 and add a test so we don't have this happen again. > Remove commons-lang as a dependency > --- > > Key: SOLR-9079 > URL: https://issues.apache.org/jira/browse/SOLR-9079 > Project: Solr > Issue Type: Improvement >Reporter: Christine Poerschke >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.1, master (9.0) > > Attachments: SOLR-9079.patch, SOLR-9079.patch, SOLR-9079.patch > > Time Spent: 50m > Remaining Estimate: 0h > > Current version used is [/commons-lang/commons-lang = > 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68] > and a key motivation would be to have > [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html] > APIs available e.g. > [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html] > as an alternative to > [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java] > variant. > [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e] > dev list posting reports on exploring use of 3.4 instead of 2.6 and > concludes with the discovery of an optional zookeeper dependency on > commons-lang-2.4 version. > So upgrading commons-lang can't happen anytime soon but this ticket here to > track motivations and findings so far for future reference. > selected links into other relevant dev list threads: > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804153#comment-16804153 ] Alan Woodward commented on LUCENE-8745: --- Can you not use a ConditionalTokenFilter for this? > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > > Right now, SynonymGraphFilter operates on the original input term, and the > repeated term that is marked as Keyword. This issue is to optionally keep it > from operating on the term marked as Keyword, just as like stemmers (should) > behave. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work
[ https://issues.apache.org/jira/browse/SOLR-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804143#comment-16804143 ] Erick Erickson commented on SOLR-11579: --- Is this still true? > Building Solr using Java 9 and Maven doesn't work > - > > Key: SOLR-11579 > URL: https://issues.apache.org/jira/browse/SOLR-11579 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Affects Versions: 8.0 > Environment: Apache Maven 3.5.0 > (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00) > Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0 > Java version: 9, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac" > java version "9" > Java(TM) SE Runtime Environment (build 9+181) > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >Reporter: Daniel Collins >Priority: Minor > Labels: maven, maven-enforcer-plugin > Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4 > > > I'm calling this minor as I don't believe we officially support Java 9 (but > correct me if I'm wrong), and I've only tried on master (again, I don't > *think* branch_7x is setup for Java 9?) > Several issues/notes: > # enforcer plugin breaks if you try to do mvn install > # javadoc plugin breaks if you try to do mvn javadoc:jar > # warnings from groovy-maven-plugin (TODO) > # a lot of the maven plugins are quite old > # forbiddenapis has some issues with Solr (I assume due to module split-up, > javax is no longer part of core) (TODO) > I have patches for 1, 2, and 4. Still working on 3 and 5. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11196) Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0
[
https://issues.apache.org/jira/browse/SOLR-11196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-11196.
---
Resolution: Won't Fix
There is no evidence that this is anything other than a mis-configured system.
> Solr 6.5.0 consuming entire Heap suddenly while working smoothly on Solr 6.1.0
> --
>
> Key: SOLR-11196
> URL: https://issues.apache.org/jira/browse/SOLR-11196
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5, 6.6
>Reporter: Amit
>Priority: Major
>
> Please note, this issue does not occurs on Solr-6.1.0 while the same occurs
> on Solr-6.5.0 and above. To fix this we had to move back to Solr-6.1.0
> version.
> We have been hit by a Solr Behavior in production which we are unable to
> debug. To start with here are the configurations for solr:
> Solr Version: 6.5, Master with 1 Slave of the same configuration as mentioned
> below.
> *JVM Config:*
>
> {code:java}
> -Xms2048m
> -Xmx4096m
> -XX:+ParallelRefProcEnabled
> -XX:+UseCMSInitiatingOccupancyOnly
> -XX:CMSInitiatingOccupancyFraction=50
> {code}
> Rest all are default values.
> *Solr Config* :
>
> {code:java}
>
>
> {solr.autoCommit.maxTime:30}
> false
>
>
>
> {solr.autoSoftCommit.maxTime:90}
>
>
>
> 1024
>autowarmCount="0" />
>autowarmCount="0" />
>autowarmCount="0" />
>initialSize="0" autowarmCount="10" regenerator="solr.NoOpRegenerator" />
> true
> 20
> ${solr.query.max.docs:40}
>
> false
> 2
>
> {code}
> *The Host (AWS) configurations are:*
> RAM: 7.65GB
> Cores: 4
> Now, our solr works perfectly fine for hours and sometimes for days but
> sometimes suddenly memory jumps up and the GC kicks in causing long big
> pauses with not much to recover. We are seeing this happening most often when
> one or multiple segments gets added or deleted post a hard commit. It doesn't
> matter how many documents got indexed. The images attached shows that just 1
> document was indexed, causing an addition of one segment and it all got
> messed up till we restarted the Solr.
> Here are the images from NewRelic and Sematext (Kindly click on the links to
> view):
> [JVM Heap Memory Image | https://i.stack.imgur.com/9dQAy.png]
> [1 Document and 1 Segment addition Image |
> https://i.stack.imgur.com/6N4FC.png]
> Update: Here is the JMap output when SOLR last died, we have now increased
> the JVM memory to xmx of 12GB:
>
> {code:java}
> num #instances #bytes class name
> --
> 1: 11210921 1076248416
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
> 2: 10623486 934866768 [Lorg.apache.lucene.index.TermState;
> 3: 15567646 475873992 [B
> 4: 10623485 424939400
> org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
> 5: 15508972 372215328 org.apache.lucene.util.BytesRef
> 6: 15485834 371660016 org.apache.lucene.index.Term
> 7: 15477679 371464296
> org.apache.lucene.search.spans.SpanTermQuery
> 8: 10623486 339951552 org.apache.lucene.index.TermContext
> 9: 1516724 150564320 [Ljava.lang.Object;
> 10:724486 50948800 [C
> 11: 1528110 36674640 java.util.ArrayList
> 12:849884 27196288
> org.apache.lucene.search.spans.SpanNearQuery
> 13:582008 23280320
> org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
> 14:481601 23116848 org.apache.lucene.document.FieldType
> 15:623073 19938336 org.apache.lucene.document.StoredField
> 16:721649 17319576 java.lang.String
> 17: 327297329640 [J
> 18: 146435788376 [F
> {code}
> The load on Solr is not much - max it goes to 2000 requests per minute. The
> indexing load can sometimes be in burst but most of the time its pretty low.
> But as mentioned above sometimes even a single document indexing can put solr
> into tizzy and sometimes it just works like a charm.
> Edit :
> The last configuration on which 6.1 works but not 6.5 is:
> *JVM Config:*
>
> {code:java}
> Xms: 2 GB
> Xmx: 12 GB
> {code}
> *Solr Config:*
> We also removed soft commit.
> {code:java}
>
>
>${solr.autoCommit.maxTime:30}
>true
>
> {code}
> *The Host (AWS) configurations:*
> RAM: 16GB
> Cores: 4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mai
[jira] [Commented] (SOLR-13337) TermsComponent sharded and terms.sort=index performance
[
https://issues.apache.org/jira/browse/SOLR-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804134#comment-16804134
]
Lucene/Solr QA commented on SOLR-13337:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 4m 16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 4m 16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 4m 16s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 89m
25s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}100m 42s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13337 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12963991/SOLR-13337.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 90d983c |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_191 |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/360/testReport/ |
| modules | C: solr solr/core U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/360/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> TermsComponent sharded and terms.sort=index performance
> ---
>
> Key: SOLR-13337
> URL: https://issues.apache.org/jira/browse/SOLR-13337
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
>Affects Versions: 7.7
> Environment: Linux 64bit debian
> 20-node cluster
>Reporter: Morten Bøgeskov
>Priority: Minor
> Attachments:
> 0001-SOLR-13337-Avoid-requesting-unneeded-terms-from-shar.patch,
> SOLR-13337.patch, SOLR-13337.patch, SOLR-13337.patch, SOLR-13337.patch,
> screenshot-1.png
>
>
> When the TermsComponet distributes across all shards, all (terms.limit=-1)
> are returned.
> This ought not to be needed when using terms.sort=index.
> When using terms.lower=a in small test base (400k entries) it took 8.5-11.5s
> to do a
> /terms?terms.fl=register&terms.sort=index&terms.lower=a I did not try it on
> production data (10x)
> I do get the reason for getting all terms when sorting by count, however when
> sorting by index, no more than the terms.limit number rows is required from
> any shard. Most likely some will get discarded due to presence in more than
> one shard. Given no term.min/maxcount (which definetely throws a spanner in
> the works).
>
> I've attached what I think would do the trick.
> I haven't actually tested the patch (it compiles, however some other files in
> the checkout I have doesn't: ant compile, javac: "error: cannot find symbol")
>
> Might be somewhat related issue (SOLR-2908). I didn't quite get the more
> subtle information in it.
>
>
> Tested by
> * applying patch to 7.7.1 (the one we use in production)
> * start up on spare server (during off house on test system)
> * add a replica from a collection (so that it'll serve requests)
> * request /terms?terms.fl=phrase.title&terms.sort=index&terms.lower=a from
> the instance ~30 ms
> * request the same from another unpatched instance ~17k ms
> * both returned same result
[JENKINS] Lucene-Solr-repro - Build # 3081 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3081/ [...truncated 29 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/55/consoleText [repro] Revision: 843763db061149f5c416dabaa3a5cce712fce2a4 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=HdfsCollectionsAPIDistributedZkTest -Dtests.method=testCollectionsAPI -Dtests.seed=34A99F1B2826B9A9 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=sv-SE -Dtests.timezone=Africa/Douala -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testCollectionsAPI -Dtests.seed=34A99F1B2826B9A9 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=is -Dtests.timezone=America/Porto_Acre -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=34A99F1B2826B9A9 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=et -Dtests.timezone=America/St_Barthelemy -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=CategoryRoutedAliasUpdateProcessorTest -Dtests.method=testSliceRouting -Dtests.seed=34A99F1B2826B9A9 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=ar-AE -Dtests.timezone=Africa/Harare -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 90d983cf7cd8bf867a16fe8916b523d52d72b439 [repro] git fetch [repro] git checkout 843763db061149f5c416dabaa3a5cce712fce2a4 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] CategoryRoutedAliasUpdateProcessorTest [repro] CollectionsAPIDistributedZkTest [repro] HdfsCollectionsAPIDistributedZkTest [repro] HdfsAutoAddReplicasIntegrationTest [repro] ant compile-test [...truncated 3576 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=20 -Dtests.class="*.CategoryRoutedAliasUpdateProcessorTest|*.CollectionsAPIDistributedZkTest|*.HdfsCollectionsAPIDistributedZkTest|*.HdfsAutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.seed=34A99F1B2826B9A9 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=ar-AE -Dtests.timezone=Africa/Harare -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 86432 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /usr/local/asfpackages/java/jdk1.8.0_191/jre/bin/java -ea -esa -Dtests.prefix=tests -Dtests.seed=34A99F1B2826B9A9 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=ar-AE -Dtests.timezone=Africa/Harare -Dtests.directory=random -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.luceneMatchVersion=8.1.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene/tools/junit4/logging.properties -Dtests.nightly=true -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=2 -DtempDir=./temp -Djava.io.tmpdir=./temp -Dcommon.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene -Dclover.db.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene/build/clover/db -Djava.security.policy=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-repro/lucene/tools/junit4/solr-tests.policy -Dtests.LUCENE_VERSION=8.1.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.src.home=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-
[jira] [Created] (SOLR-13352) possible deadlock/threadleak from OverseerTriggerThread/AutoScalingWatcher during close()
Hoss Man created SOLR-13352: --- Summary: possible deadlock/threadleak from OverseerTriggerThread/AutoScalingWatcher during close() Key: SOLR-13352 URL: https://issues.apache.org/jira/browse/SOLR-13352 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Hoss Man Assignee: Hoss Man A recent jenkins failure in TestSimTriggerIntegration lead me to what appears to be a "lock leak" situation in OverseerTriggerThread in how the "updateLock" object is dealt with in the event that the OverseerTriggerThread is closed. It's possible that this only affects tests using the SimCloudManager when calling "simRestartOverseer" -- but I _believe_ this can lead also lead to an actual deadlock / threadleak situation in a thread running AutoScalingWatcher (that hold a refrefrences to OverseerTriggerThread and every object reachable from it) when the OverseerTriggerThread is closed as part of a real Solr shutdown ... which i think would cause the JVM to stall untill externally killed. If my analysis of the test failure (to follow in comment) is correct, then even even if this bug isn't likely to affect real world solr instances (and only surfaces because of how OverseerTriggerThread is used in SimCloudManager) the fix to OverseerTriggerThread is a trivial change to follow locking best practices (patch to follow) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270067277
##
File path:
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
##
@@ -645,32 +660,126 @@ boolean getUpdatedDocument(AddUpdateCommand cmd, long
versionOnUpdate) throws IO
}
// full (non-inplace) atomic update
+final boolean isDeeplyNestedSchema =
req.getSchema().isUsableForChildDocs() &&
req.getSchema().hasExplicitField(IndexSchema.NEST_PATH_FIELD_NAME);
SolrInputDocument sdoc = cmd.getSolrInputDocument();
BytesRef id = cmd.getIndexedId();
-SolrInputDocument oldDoc =
RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id);
+SolrInputDocument completeHierarchy =
RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id,
RealTimeGetComponent.Resolution.ROOT_WITH_CHILDREN);
-if (oldDoc == null) {
- // create a new doc by default if an old one wasn't found
- if (versionOnUpdate <= 0) {
-oldDoc = new SolrInputDocument();
- } else {
+if (completeHierarchy == null) {
+ if (versionOnUpdate > 0) {
// could just let the optimistic locking throw the error
throw new SolrException(ErrorCode.CONFLICT, "Document not found for
update. id=" + cmd.getPrintableId());
}
} else {
- oldDoc.remove(CommonParams.VERSION_FIELD);
+ completeHierarchy.remove(CommonParams.VERSION_FIELD);
}
-cmd.solrDoc = docMerger.merge(sdoc, oldDoc);
+SolrInputDocument mergedDoc;
Review comment:
I think much of the changes you did here in
DistributedUpdateProcessor.getUpdatedDocument (and new supporting methods
added), should move to AtomicUpdateDocumentMerger since it has to do with the
intricacies of merging documents. This code is distracting in
DistributedUpdateProcessor which has plenty of complicated responsibilities
otherwise. WDYT?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270096287
##
File path:
solr/core/src/test/org/apache/solr/update/processor/NestedAtomicUpdateTest.java
##
@@ -0,0 +1,659 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.update.processor;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.List;
+import java.util.stream.Collectors;
+import java.util.stream.IntStream;
+
+import org.apache.lucene.util.BytesRef;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.SolrInputField;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.handler.component.RealTimeGetComponent;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+public class NestedAtomicUpdateTest extends SolrTestCaseJ4 {
+
+ private final static String VERSION = "_version_";
+
+ @BeforeClass
+ public static void beforeTests() throws Exception {
+initCore("solrconfig-block-atomic-update.xml", "schema-nest.xml"); // use
"nest" schema
+ }
+
+ @Before
+ public void before() {
+clearIndex();
+assertU(commit());
+ }
+
+ @Test
+ public void testMergeChildDoc() throws Exception {
+SolrInputDocument newChildDoc = sdoc("id", "3", "cat_ss", "child");
+SolrInputDocument addedDoc = sdoc("id", "1",
+"cat_ss", Collections.singletonMap("add", "bbb"),
+"child", Collections.singletonMap("add", sdocs(newChildDoc)));
+
+SolrInputDocument dummyBlock = sdoc("id", "1",
+"cat_ss", new ArrayList<>(Arrays.asList("aaa", "ccc")),
+"_root_", "1", "child", new ArrayList<>(sdocs(addedDoc)));
+dummyBlock.removeField(VERSION);
+
+SolrInputDocument preMergeDoc = new SolrInputDocument(dummyBlock);
+AtomicUpdateDocumentMerger docMerger = new
AtomicUpdateDocumentMerger(req());
+docMerger.merge(addedDoc, dummyBlock);
+assertEquals("merged document should have the same id",
preMergeDoc.getFieldValue("id"), dummyBlock.getFieldValue("id"));
+assertDocContainsSubset(preMergeDoc, dummyBlock);
+assertDocContainsSubset(addedDoc, dummyBlock);
+assertDocContainsSubset(newChildDoc, (SolrInputDocument) ((List)
dummyBlock.getFieldValues("child")).get(1));
+assertEquals(dummyBlock.getFieldValue("id"),
dummyBlock.getFieldValue("id"));
+ }
+
+ @Test
+ public void testBlockAtomicInplaceUpdates() throws Exception {
+SolrInputDocument doc = sdoc("id", "1", "string_s", "root");
+addDoc(adoc(doc), "nested-rtg");
+
+assertU(commit());
+
+assertQ(req("q", "id:1", "fl", "*"),
+"//*[@numFound='1']",
+"//doc[1]/str[@name='id']=1"
+);
+
+List docs = IntStream.range(10, 20).mapToObj(x ->
sdoc("id", String.valueOf(x), "string_s",
+"child", "inplace_updatable_int", "0")).collect(Collectors.toList());
+doc = sdoc("id", "1", "children", Collections.singletonMap("add", docs));
+addAndGetVersion(doc, params("update.chain", "nested-rtg", "wt", "json",
"_route_", "1"));
+
+assertU(commit());
+
+
+assertQ(req("q", "_root_:1", "fl", "*", "rows", "11"),
+"//*[@numFound='11']"
+);
+
+assertQ(req("q", "string_s:child", "fl", "*"),
+"//*[@numFound='10']",
+"*[count(//str[@name='string_s'][.='child'])=10]"
+);
+
+for(int i = 10; i < 20; ++i) {
+ doc = sdoc("id", String.valueOf(i), "inplace_updatable_int",
Collections.singletonMap("inc", "1"));
+ addAndGetVersion(doc, params("update.chain", "nested-rtg", "wt", "json",
"_route_", "1"));
+ assertU(commit());
+}
+
+for(int i = 10; i < 20; ++i) {
+ doc = sdoc("id", String.valueOf(i), "inplace_updatable_int",
Collections.singletonMap("inc", "1"));
+ addAndGetVersion(doc, params("update.chain", "nested-rtg", "wt", "json",
"_route_", "1"));
+ assertU(commit());
+}
+
+// ensure updates work when block has more than 10 children
+for(int i = 10; i < 20; ++i) {
+ docs = IntStream.range(i * 10, (i * 10) + 5).mapToObj(x -> sdoc("id",
String.value
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270086512
##
File path:
solr/core/src/test/org/apache/solr/cloud/NestedShardedAtomicUpdateTest.java
##
@@ -0,0 +1,191 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud;
+
+import java.io.IOException;
+import java.util.List;
+
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.response.QueryResponse;
+import org.apache.solr.common.SolrDocument;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.params.ModifiableSolrParams;
+import org.apache.solr.common.params.SolrParams;
+import org.junit.Test;
+
+public class NestedShardedAtomicUpdateTest extends
AbstractFullDistribZkTestBase {
+
+ public NestedShardedAtomicUpdateTest() {
+stress = 0;
+sliceCount = 4;
+schemaString = "sharded-block-schema.xml";
+ }
+
+ @Override
+ protected String getCloudSolrConfig() {
+return "solrconfig-block-atomic-update.xml";
+ }
+
+ @Override
+ protected String getCloudSchemaFile() {
+return "sharded-block-schema.xml";
+ }
+
+ @Test
+ @ShardsFixed(num = 4)
+ public void test() throws Exception {
+boolean testFinished = false;
+try {
+ doNestedInplaceUpdateTest();
+ doRootShardRoutingTest();
+ testFinished = true;
+} finally {
+ if (!testFinished) {
+printLayoutOnTearDown = true;
+ }
+}
+ }
+
+ public void doRootShardRoutingTest() throws Exception {
+assertEquals(4,
cloudClient.getZkStateReader().getClusterState().getCollection(DEFAULT_COLLECTION).getSlices().size());
+final String[] ids = {"c", "d", "e", "f"};
+
+assertEquals("size of ids to index should be the same as the number of
clients", clients.size(), ids.length);
+// for now, we know how ranges will be distributed to shards.
+// may have to look it up in clusterstate if that assumption changes.
+
+SolrInputDocument doc = sdoc("id", "a", "level_s", "root");
+
+final SolrParams params = new ModifiableSolrParams().set("update.chain",
"nested-rtg").set("wt", "json").set("_route_", "a");
+
+int which = (params.get("_route_").hashCode() & 0x7fff) %
clients.size();
+SolrClient aClient = clients.get(which);
+
+indexDoc(aClient, params, doc);
+
+aClient.commit();
Review comment:
again; some of these commits are superfluous and would better be randomized
so exercise different internal code paths.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270085155
##
File path:
solr/core/src/test-files/solr/collection1/conf/solrconfig-block-atomic-update.xml
##
@@ -0,0 +1,64 @@
+
+
+
+
+
+
+ ${tests.luceneMatchVersion:LATEST}
+ http://www.w3.org/2001/XInclude"/>
+
+
+
+
+
+
+
+
+ ${solr.autoCommit.maxTime:-1}
+
+
+
+
+
+ ${solr.ulog.dir:}
+
+
+
+ ${solr.commitwithin.softcommit:true}
+
+
+
+
+
Review comment:
BTW your comment here is about the schema but this review thread is on
solrconfig.xml which I think could be a stock/basic one instead of yet another
test config file.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270092984
##
File path:
solr/core/src/test/org/apache/solr/cloud/NestedShardedAtomicUpdateTest.java
##
@@ -0,0 +1,191 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud;
+
+import java.io.IOException;
+import java.util.List;
+
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.response.QueryResponse;
+import org.apache.solr.common.SolrDocument;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.params.ModifiableSolrParams;
+import org.apache.solr.common.params.SolrParams;
+import org.junit.Test;
+
+public class NestedShardedAtomicUpdateTest extends
AbstractFullDistribZkTestBase {
+
+ public NestedShardedAtomicUpdateTest() {
+stress = 0;
+sliceCount = 4;
+schemaString = "sharded-block-schema.xml";
+ }
+
+ @Override
+ protected String getCloudSolrConfig() {
+return "solrconfig-block-atomic-update.xml";
+ }
+
+ @Override
+ protected String getCloudSchemaFile() {
+return "sharded-block-schema.xml";
+ }
+
+ @Test
+ @ShardsFixed(num = 4)
+ public void test() throws Exception {
+boolean testFinished = false;
+try {
+ doNestedInplaceUpdateTest();
+ doRootShardRoutingTest();
+ testFinished = true;
+} finally {
+ if (!testFinished) {
+printLayoutOnTearDown = true;
+ }
+}
+ }
+
+ public void doRootShardRoutingTest() throws Exception {
+assertEquals(4,
cloudClient.getZkStateReader().getClusterState().getCollection(DEFAULT_COLLECTION).getSlices().size());
+final String[] ids = {"c", "d", "e", "f"};
+
+assertEquals("size of ids to index should be the same as the number of
clients", clients.size(), ids.length);
+// for now, we know how ranges will be distributed to shards.
+// may have to look it up in clusterstate if that assumption changes.
+
+SolrInputDocument doc = sdoc("id", "a", "level_s", "root");
+
+final SolrParams params = new ModifiableSolrParams().set("update.chain",
"nested-rtg").set("wt", "json").set("_route_", "a");
+
+int which = (params.get("_route_").hashCode() & 0x7fff) %
clients.size();
+SolrClient aClient = clients.get(which);
+
+indexDoc(aClient, params, doc);
+
+aClient.commit();
+
+doc = sdoc("id", "a", "children", map("add", sdocs(sdoc("id", "b",
"level_s", "child";
+
+indexDoc(aClient, params, doc);
+aClient.commit();
+
+int i = 0;
+for (SolrClient client : clients) {
+
+ doc = sdoc("id", "b", "grandChildren", map("add", sdocs(sdoc("id",
ids[i], "level_s", "grand_child";
+
+ indexDocAndRandomlyCommit(client, params, doc);
+
+ doc = sdoc("id", "c", "inplace_updatable_int", map("inc", "1"));
+
+ indexDocAndRandomlyCommit(client, params, doc);
+
+ // assert RTG request respects _route_ param
+ QueryResponse routeRsp = client.query(params("qt","/get", "id","b",
"_route_", "a"));
+ SolrDocument results = (SolrDocument) routeRsp.getResponse().get("doc");
+ assertNotNull("RTG should find doc because _route_ was set to the root
documents' ID", results);
+ assertEquals("b", results.getFieldValue("id"));
+
+ // assert all docs are indexed under the same root
+ client.commit();
+ assertEquals(0, client.query(new ModifiableSolrParams().set("q",
"-_root_:a")).getResults().size());
+
+ // assert all docs are indexed inside the same block
+ QueryResponse rsp = client.query(params("qt","/get", "id","a", "fl", "*,
[child]"));
+ SolrDocument val = (SolrDocument) rsp.getResponse().get("doc");
+ assertEquals("a", val.getFieldValue("id"));
+ List children = (List) val.getFieldValues("children");
+ assertEquals(1, children.size());
+ SolrDocument childDoc = children.get(0);
+ assertEquals("b", childDoc.getFieldValue("id"));
+ List grandChildren = (List)
childDoc.getFieldValues("grandChildren");
+ assertEquals(++i, grandChildren.size());
+ SolrDocument grandChild = grandChildren.
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270092633
##
File path:
solr/core/src/test/org/apache/solr/cloud/NestedShardedAtomicUpdateTest.java
##
@@ -0,0 +1,191 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud;
+
+import java.io.IOException;
+import java.util.List;
+
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.response.QueryResponse;
+import org.apache.solr.common.SolrDocument;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.params.ModifiableSolrParams;
+import org.apache.solr.common.params.SolrParams;
+import org.junit.Test;
+
+public class NestedShardedAtomicUpdateTest extends
AbstractFullDistribZkTestBase {
+
+ public NestedShardedAtomicUpdateTest() {
+stress = 0;
+sliceCount = 4;
+schemaString = "sharded-block-schema.xml";
+ }
+
+ @Override
+ protected String getCloudSolrConfig() {
+return "solrconfig-block-atomic-update.xml";
+ }
+
+ @Override
+ protected String getCloudSchemaFile() {
+return "sharded-block-schema.xml";
+ }
+
+ @Test
+ @ShardsFixed(num = 4)
+ public void test() throws Exception {
+boolean testFinished = false;
+try {
+ doNestedInplaceUpdateTest();
+ doRootShardRoutingTest();
+ testFinished = true;
+} finally {
+ if (!testFinished) {
+printLayoutOnTearDown = true;
+ }
+}
+ }
+
+ public void doRootShardRoutingTest() throws Exception {
+assertEquals(4,
cloudClient.getZkStateReader().getClusterState().getCollection(DEFAULT_COLLECTION).getSlices().size());
+final String[] ids = {"c", "d", "e", "f"};
+
+assertEquals("size of ids to index should be the same as the number of
clients", clients.size(), ids.length);
+// for now, we know how ranges will be distributed to shards.
+// may have to look it up in clusterstate if that assumption changes.
+
+SolrInputDocument doc = sdoc("id", "a", "level_s", "root");
+
+final SolrParams params = new ModifiableSolrParams().set("update.chain",
"nested-rtg").set("wt", "json").set("_route_", "a");
+
+int which = (params.get("_route_").hashCode() & 0x7fff) %
clients.size();
+SolrClient aClient = clients.get(which);
+
+indexDoc(aClient, params, doc);
+
+aClient.commit();
+
+doc = sdoc("id", "a", "children", map("add", sdocs(sdoc("id", "b",
"level_s", "child";
+
+indexDoc(aClient, params, doc);
+aClient.commit();
+
+int i = 0;
+for (SolrClient client : clients) {
+
+ doc = sdoc("id", "b", "grandChildren", map("add", sdocs(sdoc("id",
ids[i], "level_s", "grand_child";
+
+ indexDocAndRandomlyCommit(client, params, doc);
+
+ doc = sdoc("id", "c", "inplace_updatable_int", map("inc", "1"));
+
+ indexDocAndRandomlyCommit(client, params, doc);
+
+ // assert RTG request respects _route_ param
+ QueryResponse routeRsp = client.query(params("qt","/get", "id","b",
"_route_", "a"));
+ SolrDocument results = (SolrDocument) routeRsp.getResponse().get("doc");
+ assertNotNull("RTG should find doc because _route_ was set to the root
documents' ID", results);
+ assertEquals("b", results.getFieldValue("id"));
+
+ // assert all docs are indexed under the same root
+ client.commit();
+ assertEquals(0, client.query(new ModifiableSolrParams().set("q",
"-_root_:a")).getResults().size());
+
+ // assert all docs are indexed inside the same block
+ QueryResponse rsp = client.query(params("qt","/get", "id","a", "fl", "*,
[child]"));
+ SolrDocument val = (SolrDocument) rsp.getResponse().get("doc");
+ assertEquals("a", val.getFieldValue("id"));
+ List children = (List) val.getFieldValues("children");
+ assertEquals(1, children.size());
+ SolrDocument childDoc = children.get(0);
+ assertEquals("b", childDoc.getFieldValue("id"));
+ List grandChildren = (List)
childDoc.getFieldValues("grandChildren");
+ assertEquals(++i, grandChildren.size());
Review comment:
aha; I see now. This is
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638 URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270078602 ## File path: solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java ## @@ -645,32 +660,126 @@ boolean getUpdatedDocument(AddUpdateCommand cmd, long versionOnUpdate) throws IO } // full (non-inplace) atomic update +final boolean isDeeplyNestedSchema = req.getSchema().isUsableForChildDocs() && req.getSchema().hasExplicitField(IndexSchema.NEST_PATH_FIELD_NAME); SolrInputDocument sdoc = cmd.getSolrInputDocument(); BytesRef id = cmd.getIndexedId(); -SolrInputDocument oldDoc = RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id); +SolrInputDocument completeHierarchy = RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id, RealTimeGetComponent.Resolution.ROOT_WITH_CHILDREN); Review comment: I think "oldDocWithChildren" would be a better name. The semantics that it's the old document is important. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638 URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270097963 ## File path: solr/solr-ref-guide/src/the-terms-component.adoc ## @@ -301,3 +301,5 @@ See the section <
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270075968
##
File path:
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
##
@@ -645,32 +660,126 @@ boolean getUpdatedDocument(AddUpdateCommand cmd, long
versionOnUpdate) throws IO
}
// full (non-inplace) atomic update
+final boolean isDeeplyNestedSchema =
req.getSchema().isUsableForChildDocs() &&
req.getSchema().hasExplicitField(IndexSchema.NEST_PATH_FIELD_NAME);
SolrInputDocument sdoc = cmd.getSolrInputDocument();
BytesRef id = cmd.getIndexedId();
-SolrInputDocument oldDoc =
RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id);
+SolrInputDocument completeHierarchy =
RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id,
RealTimeGetComponent.Resolution.ROOT_WITH_CHILDREN);
-if (oldDoc == null) {
- // create a new doc by default if an old one wasn't found
- if (versionOnUpdate <= 0) {
-oldDoc = new SolrInputDocument();
- } else {
+if (completeHierarchy == null) {
+ if (versionOnUpdate > 0) {
// could just let the optimistic locking throw the error
throw new SolrException(ErrorCode.CONFLICT, "Document not found for
update. id=" + cmd.getPrintableId());
}
} else {
- oldDoc.remove(CommonParams.VERSION_FIELD);
+ completeHierarchy.remove(CommonParams.VERSION_FIELD);
}
-cmd.solrDoc = docMerger.merge(sdoc, oldDoc);
+SolrInputDocument mergedDoc;
+if(idField == null || completeHierarchy == null) {
+ // create a new doc by default if an old one wasn't found
+ mergedDoc = docMerger.merge(sdoc, new SolrInputDocument());
+} else {
+ if(isDeeplyNestedSchema && !isRootDoc(sdoc, completeHierarchy)) {
Review comment:
I suggest commenting: "non-root docs to update must be provided with a
_root_ field for this to work" (assuming you agree this is true; logic seems
to show this)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #455: SOLR-12638
dsmiley commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r270084153
##
File path:
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
##
@@ -1032,6 +1151,24 @@ protected void assertNotFinished() {
finished = true;
}
+ /**
+ *
+ * @return whether this update changes a value of a block
+ */
+ public static boolean shouldRefreshUlogCaches(AddUpdateCommand cmd) {
Review comment:
Can we make this logic more efficient by adding a field to AddUpdateCommand
that declares (a) is this update an atomic update, and furthermore, did it
involve nested documents? Perhaps two separate `Boolean`s, null meaning not
yet calculated. By this juncture in the code I think we've already determined
these things and I'd like to avoid potential overhead per document going into
Solr. Lambda's can add up.
typo "update.q" => "update"
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency
[ https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804098#comment-16804098 ] Kevin Risden commented on SOLR-9079: Thanks for pointing this out [~janhoy] - I'll take a look later today and fix. > Remove commons-lang as a dependency > --- > > Key: SOLR-9079 > URL: https://issues.apache.org/jira/browse/SOLR-9079 > Project: Solr > Issue Type: Improvement >Reporter: Christine Poerschke >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.1, master (9.0) > > Attachments: SOLR-9079.patch, SOLR-9079.patch, SOLR-9079.patch > > Time Spent: 50m > Remaining Estimate: 0h > > Current version used is [/commons-lang/commons-lang = > 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68] > and a key motivation would be to have > [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html] > APIs available e.g. > [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html] > as an alternative to > [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java] > variant. > [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e] > dev list posting reports on exploring use of 3.4 instead of 2.6 and > concludes with the discovery of an optional zookeeper dependency on > commons-lang-2.4 version. > So upgrading commons-lang can't happen anytime soon but this ticket here to > track motivations and findings so far for future reference. > selected links into other relevant dev list threads: > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E > * > http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804099#comment-16804099
]
Jan Høydahl commented on SOLR-12860:
I attached [^SOLR-12860.patch] as an attempt to make the scheduled executor
behave like a "Solr threadpool". Seems to work with manual testing here. Not
sure if it is the best solution though. [~ab]?
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Attachments: SOLR-12860.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecuto
[jira] [Updated] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-12860:
---
Attachment: SOLR-12860.patch
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Attachments: SOLR-12860.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_112]
> at
> java.util.concurrent.ThreadPoolExecutor.runWor
[jira] [Commented] (SOLR-9079) Remove commons-lang as a dependency
[
https://issues.apache.org/jira/browse/SOLR-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804096#comment-16804096
]
Jan Høydahl commented on SOLR-9079:
---
This seems to break parsing of booleans in {{SolrCli}}. Try this
{code:java}
> bin/solr auth enable -credentials solr:solr -blockUnknown true
Argument [blockUnknown] must be either true or false, but was [true]{code}
So the change in SolrCli should be reverted back:
{code:java}
- if (Boolean.parseBoolean(value)) {
+ final Boolean parsedBoolean = BooleanUtils.toBooleanObject(value);
+ if (parsedBoolean == null) {
echo("Argument [" + argName + "] must be either true or false, but was [" +
value + "]");
exit(1);
}
{code}
> Remove commons-lang as a dependency
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-9079.patch, SOLR-9079.patch, SOLR-9079.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Current version used is [/commons-lang/commons-lang =
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
> and a key motivation would be to have
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
> APIs available e.g.
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
> as an alternative to
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
> variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
> dev list posting reports on exploring use of 3.4 instead of 2.6 and
> concludes with the discovery of an optional zookeeper dependency on
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> *
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> *
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> *
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-8745: -- Attachment: LUCENE-8745.patch > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > > Right now, SynonymGraphFilter operates on the original input term, and the > repeated term that is marked as Keyword. This issue is to optionally keep it > from operating on the term marked as Keyword, just as like stemmers (should) > behave. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-8745: -- Environment: (was: Right now, SynonymGraphFilter operates on the original input term, and the repeated term that is marked as Keyword. This issue is to optionally keep it from operating on the term marked as Keyword, just as like stemmers (should) behave.) > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-8745: -- Description: Right now, SynonymGraphFilter operates on the original input term, and the repeated term that is marked as Keyword. This issue is to optionally keep it from operating on the term marked as Keyword, just as like stemmers (should) behave. > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > > Right now, SynonymGraphFilter operates on the original input term, and the > repeated term that is marked as Keyword. This issue is to optionally keep it > from operating on the term marked as Keyword, just as like stemmers (should) > behave. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
Markus Jelsma created LUCENE-8745: - Summary: SynonymGraphFilter to optionally skip keywords Key: LUCENE-8745 URL: https://issues.apache.org/jira/browse/LUCENE-8745 Project: Lucene - Core Issue Type: Improvement Environment: Right now, SynonymGraphFilter operates on the original input term, and the repeated term that is marked as Keyword. This issue is to optionally keep it from operating on the term marked as Keyword, just as like stemmers (should) behave. Reporter: Markus Jelsma Fix For: 8.1, master (9.0) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804034#comment-16804034
]
Lorenzo commented on SOLR-12860:
Thanks for the feedback, not yet. I will give it a shot.
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [?:1.8.0_112]
> at
> java.util.conc
[GitHub] [lucene-solr] craigmamakin closed pull request #625: Ravn 1578
craigmamakin closed pull request #625: Ravn 1578 URL: https://github.com/apache/lucene-solr/pull/625 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] craigmamakin commented on issue #625: Ravn 1578
craigmamakin commented on issue #625: Ravn 1578 URL: https://github.com/apache/lucene-solr/pull/625#issuecomment-477611974 @endika-ravn This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] craigmamakin opened a new pull request #625: Ravn 1578
craigmamakin opened a new pull request #625: Ravn 1578 URL: https://github.com/apache/lucene-solr/pull/625 feedback needed please This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 316 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/316/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic
Error Message:
{} expected:<1> but was:<0>
Stack Trace:
java.lang.AssertionError: {} expected:<1> but was:<0>
at
__randomizedtesting.SeedInfo.seed([5BCE4BBDBE317EC9:F03456A861EDF8E7]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest.testBasic(SolrRrdBackendFactoryTest.java:92)
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:567)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:835)
Build Log:
[...truncated 2099 lines...]
[junit4] JVM J1: stderr was not empty, see:
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/lucene/build/core/test/temp/junit4-J1-20190328_101638_1161443494727373774.syserr
[junit
[jira] [Created] (LUCENE-8744) TestTessellator#testLinesIntersect failure
Ignacio Vera created LUCENE-8744:
Summary: TestTessellator#testLinesIntersect failure
Key: LUCENE-8744
URL: https://issues.apache.org/jira/browse/LUCENE-8744
Project: Lucene - Core
Issue Type: Test
Reporter: Ignacio Vera
Reproduce with:
{code:java}
ant test -Dtestcase=TestTessellator -Dtests.method=testLinesIntersect
-Dtests.seed=D8AE5A1A4CA3A81D -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=ar-IQ -Dtests.timezone=Europe/Sarajevo -Dtests.asserts=true
-Dtests.file.encoding=UTF-8{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803948#comment-16803948
]
Jan Høydahl commented on SOLR-12860:
Have you tried to get the MetricsHistoryHandler to use a Solr thread? I'm sure
there was as reason for this code path? [~noble.paul]
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_112]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.
[jira] [Commented] (SOLR-13351) Workaround for VELOCITY-908
[ https://issues.apache.org/jira/browse/SOLR-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803922#comment-16803922 ] ASF subversion and git services commented on SOLR-13351: Commit 543ea46afad1f52de82b9b820fba0fe7458bae42 in lucene-solr's branch refs/heads/branch_8x from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=543ea46 ] SOLR-13351: Workaround for VELOCITY-908 Signed-off-by: Kevin Risden > Workaround for VELOCITY-908 > --- > > Key: SOLR-13351 > URL: https://issues.apache.org/jira/browse/SOLR-13351 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Velocity >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13351.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Workaround locale handling VELOCITY-908 that is fixed in Velocity 2.1 (not > released yet). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] risdenk merged pull request #623: SOLR-13351: Workaround for VELOCITY-908
risdenk merged pull request #623: SOLR-13351: Workaround for VELOCITY-908 URL: https://github.com/apache/lucene-solr/pull/623 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13351) Workaround for VELOCITY-908
[ https://issues.apache.org/jira/browse/SOLR-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803921#comment-16803921 ] ASF subversion and git services commented on SOLR-13351: Commit 90d983cf7cd8bf867a16fe8916b523d52d72b439 in lucene-solr's branch refs/heads/master from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=90d983c ] SOLR-13351: Workaround for VELOCITY-908 Signed-off-by: Kevin Risden > Workaround for VELOCITY-908 > --- > > Key: SOLR-13351 > URL: https://issues.apache.org/jira/browse/SOLR-13351 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - Velocity >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13351.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Workaround locale handling VELOCITY-908 that is fixed in Velocity 2.1 (not > released yet). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13338) HdfsAutoAddReplicasIntegrationTest failures
[ https://issues.apache.org/jira/browse/SOLR-13338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803918#comment-16803918 ] Kevin Risden commented on SOLR-13338: - new failure after ~7 days. https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.x/55/ > HdfsAutoAddReplicasIntegrationTest failures > --- > > Key: SOLR-13338 > URL: https://issues.apache.org/jira/browse/SOLR-13338 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Hadoop Integration, hdfs, Tests >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > > HdfsAutoAddReplicasIntegrationTest failures have increased after SOLR-13330 > (previously failed a different way with SOLR-13060), but they are starting to > reproduce and beasting causes failures locally. They fail the same each time. > Planning to figure out what is going on. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] moshebla commented on a change in pull request #455: SOLR-12638
moshebla commented on a change in pull request #455: SOLR-12638
URL: https://github.com/apache/lucene-solr/pull/455#discussion_r269989941
##
File path:
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
##
@@ -645,32 +660,78 @@ boolean getUpdatedDocument(AddUpdateCommand cmd, long
versionOnUpdate) throws IO
}
// full (non-inplace) atomic update
+final boolean isDeeplyNestedSchema =
req.getSchema().isUsableForChildDocs() &&
req.getSchema().hasExplicitField(IndexSchema.NEST_PATH_FIELD_NAME);
SolrInputDocument sdoc = cmd.getSolrInputDocument();
BytesRef id = cmd.getIndexedId();
-SolrInputDocument oldDoc =
RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id);
+SolrInputDocument nestedDoc =
RealTimeGetComponent.getInputDocument(cmd.getReq().getCore(), id,
RealTimeGetComponent.Resolution.ROOT_WITH_CHILDREN);
-if (oldDoc == null) {
- // create a new doc by default if an old one wasn't found
- if (versionOnUpdate <= 0) {
-oldDoc = new SolrInputDocument();
- } else {
+if (nestedDoc == null) {
+ if (versionOnUpdate > 0) {
// could just let the optimistic locking throw the error
throw new SolrException(ErrorCode.CONFLICT, "Document not found for
update. id=" + cmd.getPrintableId());
}
} else {
- oldDoc.remove(CommonParams.VERSION_FIELD);
+ nestedDoc.remove(CommonParams.VERSION_FIELD);
}
-cmd.solrDoc = docMerger.merge(sdoc, oldDoc);
+SolrInputDocument mergedDoc;
+if(idField == null || nestedDoc == null) {
+ // create a new doc by default if an old one wasn't found
+ mergedDoc = docMerger.merge(sdoc, new SolrInputDocument());
+} else {
+ if(isDeeplyNestedSchema &&
nestedDoc.containsKey(IndexSchema.ROOT_FIELD_NAME) &&
Review comment:
I separated this part into a few methods, some have in-line comments,
while others have javaDocs
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth
[
https://issues.apache.org/jira/browse/SOLR-12860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803867#comment-16803867
]
Lorenzo commented on SOLR-12860:
Here is the PR with the changes and unit test.
[https://github.com/apache/lucene-solr/pull/624]
I am checking the other UTs as I think I don't like the comment in the code
{code:java}
if (!isSolrThread()) {
//if this is not running inside a Solr threadpool (as in testcases)
// then no need to add any header
return Optional.empty();
}
{code}
> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then
> uploaded the default security.json from
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>
> I'm seeing errors like these in the logs which would indicate that the
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN (MetricsHistoryHandler-12-thread-1) [ ]
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
> from server at http://192.168.0.8:7574/solr: Expected mime type
> application/octet-stream but got text/html.
>
>
> Error 401 require authentication
>
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
> require authentication
>
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:58]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
> ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df -
> jimczi - 2018-09-18 13:07:55]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_112]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [?:1.8.0_112]
> at
> java.uti
[GitHub] [lucene-solr] yael-lorenzo-olx opened a new pull request #624: WIP SOLR-12860 MetricsHistoryHandler does not work with BasicAuth
yael-lorenzo-olx opened a new pull request #624: WIP SOLR-12860 MetricsHistoryHandler does not work with BasicAuth URL: https://github.com/apache/lucene-solr/pull/624 The issue is that the following test break now. I think I don't like the deleted lines because of this coment > //if this is not running inside a Solr threadpool (as in testcases) // then no need to add any header I will be reordering some tests as the fails are not overall to understand better the situation. ``` [junit4] - org.apache.solr.handler.TestReplicationHandlerDiskOverFlow.testDiskOverFlow [junit4] - org.apache.solr.security.PKIAuthenticationIntegrationTest.testPkiAuth [junit4] - org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew [junit4] - org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenVerify [junit4] - org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenewFail [junit4] - org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testZNodePaths [junit4] - org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenCancel [junit4] - org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenSolrClient [junit4] - org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenCancelFail [junit4] - org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - 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-12) - Build # 23835 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23835/ Java: 64bit/jdk-12 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.autoscaling.NodeMarkersRegistrationTest.testNodeMarkersRegistration Error Message: Path /autoscaling/nodeLost/127.0.0.1:40559_solr exists Stack Trace: java.lang.AssertionError: Path /autoscaling/nodeLost/127.0.0.1:40559_solr exists at __randomizedtesting.SeedInfo.seed([C4ED88B95C153A26:DC5700B55220F7C9]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at org.apache.solr.cloud.autoscaling.NodeMarkersRegistrationTest.testNodeMarkersRegistration(NodeMarkersRegistrationTest.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:567) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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:835) FAILED: org.apache.solr.update.processor.CategoryRoutedAliasUpdateProcessorTest.testSliceRouting Error Message: org.apache.solr.client.solrj.
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7843 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7843/ Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC 3 tests failed. FAILED: org.apache.solr.core.ExitableDirectoryReaderTest.testCacheAssumptions Error Message: Should have fewer docs than 100 Stack Trace: java.lang.AssertionError: Should have fewer docs than 100 at __randomizedtesting.SeedInfo.seed([FDCC13AC64636D11:8AB1AC8B0A962033]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.solr.core.ExitableDirectoryReaderTest.testCacheAssumptions(ExitableDirectoryReaderTest.java:103) 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:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest Error Message: ObjectTracker found 8 object(s) that were not released!!! [SolrCore, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, Mock
Re: Intervals vs Span guidance
Hi Ramsey, My plan is to deprecate Spans and move everybody over to Intervals, which are better defined and easier to extend. We should be more or less at feature parity now, so if there are things that you can’t do in Intervals that you can in Spans, please open issues for them and I will try and get things implemented. - Alan > On 28 Mar 2019, at 08:59, Ramsey Haddad (BLOOMBERG/ LONDON) > mailto:rhadda...@bloomberg.net>> wrote: > > We are building our needed customizations/extensions on Solr/Lucene 7.7 or > 8.0 or later. We are unclear on whether/when to use Intervals vs Span. > > We know that Intervals is still maturing (new functionality in 8.0 and > probably on-going for a while?) > > But what is the overall intention/guidance? "If you need X, then use Spans." > "If you need Y, then use Intervals." "After the year 20xy, we expect everyone > to be using Intervals." ?? > > Any opinions valued. > > Thanks, > Ramsey.
Intervals vs Span guidance
We are building our needed customizations/extensions on Solr/Lucene 7.7 or 8.0 or later. We are unclear on whether/when to use Intervals vs Span. We know that Intervals is still maturing (new functionality in 8.0 and probably on-going for a while?) But what is the overall intention/guidance? "If you need X, then use Spans." "If you need Y, then use Intervals." "After the year 20xy, we expect everyone to be using Intervals." ?? Any opinions valued. Thanks, Ramsey.
[JENKINS] Lucene-Solr-BadApples-8.x-Linux (32bit/jdk1.8.0_172) - Build # 37 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/37/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseParallelGC
1 tests failed.
FAILED:
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader
Error Message:
Doc with id=4 not found in
https://127.0.0.1:43879/solr/outOfSyncReplicasCannotBecomeLeader-false due to:
Path not found: /id; rsp={doc=null}
Stack Trace:
java.lang.AssertionError: Doc with id=4 not found in
https://127.0.0.1:43879/solr/outOfSyncReplicasCannotBecomeLeader-false due to:
Path not found: /id; rsp={doc=null}
at
__randomizedtesting.SeedInfo.seed([35E2DF2425EC31FB:4B09FF34E68B3EC1]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.TestCloudConsistency.assertDocExists(TestCloudConsistency.java:283)
at
org.apache.solr.cloud.TestCloudConsistency.assertDocsExistInAllReplicas(TestCloudConsistency.java:267)
at
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:138)
at
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:97)
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:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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.TestRuleIgnoreTestSuite
[jira] [Updated] (SOLR-13337) TermsComponent sharded and terms.sort=index performance
[ https://issues.apache.org/jira/browse/SOLR-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Morten Bøgeskov updated SOLR-13337: --- Attachment: SOLR-13337.patch > TermsComponent sharded and terms.sort=index performance > --- > > Key: SOLR-13337 > URL: https://issues.apache.org/jira/browse/SOLR-13337 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Affects Versions: 7.7 > Environment: Linux 64bit debian > 20-node cluster >Reporter: Morten Bøgeskov >Priority: Minor > Attachments: > 0001-SOLR-13337-Avoid-requesting-unneeded-terms-from-shar.patch, > SOLR-13337.patch, SOLR-13337.patch, SOLR-13337.patch, SOLR-13337.patch, > screenshot-1.png > > > When the TermsComponet distributes across all shards, all (terms.limit=-1) > are returned. > This ought not to be needed when using terms.sort=index. > When using terms.lower=a in small test base (400k entries) it took 8.5-11.5s > to do a > /terms?terms.fl=register&terms.sort=index&terms.lower=a I did not try it on > production data (10x) > I do get the reason for getting all terms when sorting by count, however when > sorting by index, no more than the terms.limit number rows is required from > any shard. Most likely some will get discarded due to presence in more than > one shard. Given no term.min/maxcount (which definetely throws a spanner in > the works). > > I've attached what I think would do the trick. > I haven't actually tested the patch (it compiles, however some other files in > the checkout I have doesn't: ant compile, javac: "error: cannot find symbol") > > Might be somewhat related issue (SOLR-2908). I didn't quite get the more > subtle information in it. > > > Tested by > * applying patch to 7.7.1 (the one we use in production) > * start up on spare server (during off house on test system) > * add a replica from a collection (so that it'll serve requests) > * request /terms?terms.fl=phrase.title&terms.sort=index&terms.lower=a from > the instance ~30 ms > * request the same from another unpatched instance ~17k ms > * both returned same result > * added terms.mincount=2 to the quick request. failed with out of memory > * restarted sever with more memory (.5g -> 8g) > * request completed in ~18k ms > > I don't see how I'm supposed to unit test the functionality given it requires > a cloud instance and sufficient data to give measurable difference with or > without extra request arguments. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
