[jira] [Commented] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060472#comment-16060472 ] ASF subversion and git services commented on SOLR-10763: Commit 69d0c7065162bcc69ef67e34167562ebd27d9b73 in lucene-solr's branch refs/heads/master from [~janhoy] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=69d0c70 ] SOLR-10763: Admin UI replication tab sometimes empty when failed replications > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla >Assignee: Jan Høydahl > Fix For: master (7.0), 6.7 > > Attachments: original UI.png, SOLR-10763.patch, SOLR-10763.patch, > solr-admin-replication-fixed.png, solr default console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+173) - Build # 19942 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19942/ Java: 32bit/jdk-9-ea+173 -server -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=2412, name=testExecutor-1044-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=2412, name=testExecutor-1044-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:38833: Cannot unload non-existent core [multiunload0] at __randomizedtesting.SeedInfo.seed([4BD29869E0383185]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:222) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:372) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=10539, name=cdcr-update-log-synchronizer-4897-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@9-ea/java.lang.Thread.run(Thread.java:844)2) Thread[id=10550, name=cdcr-update-log-synchronizer-4903-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@9-ea/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=10539, name=cdcr-update-log-synchronizer-4897-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848) at java.base@9-ea/java.util.concurrent.Thr
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4097 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4097/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery Error Message: Path not found: /responseHeader/status Stack Trace: java.lang.RuntimeException: Path not found: /responseHeader/status at __randomizedtesting.SeedInfo.seed([62AEFA38CA70BC06:17A33A24DA6A7AD3]:0) at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329) at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271) at org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286) at org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184) at org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138) at org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersio
[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_131) - Build # 993 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/993/ Java: 32bit/jdk1.8.0_131 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: Error from server at http://127.0.0.1:54115/collection1: Async exception during distributed update: Error from server at http://127.0.0.1:54103/collection1: Bad Requestrequest: http://127.0.0.1:54103/collection1/update?update.chain=distrib-dup-test-chain-explicit&update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A54115%2Fcollection1%2F&wt=javabin&version=2 Remote error message: Exception writing document id 52 to the index; possible analysis error. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:54115/collection1: Async exception during distributed update: Error from server at http://127.0.0.1:54103/collection1: Bad Request request: http://127.0.0.1:54103/collection1/update?update.chain=distrib-dup-test-chain-explicit&update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A54115%2Fcollection1%2F&wt=javabin&version=2 Remote error message: Exception writing document id 52 to the index; possible analysis error. at __randomizedtesting.SeedInfo.seed([A1F08100D07AF184:29A4BEDA7E869C7C]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:594) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177) at org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:514) at org.apache.solr.cloud.BasicDistributedZkTest.testUpdateProcessorsRunOnlyOnce(BasicDistributedZkTest.java:664) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:364) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomize
[jira] [Updated] (SOLR-10177) Consolidate randomized usage of PointFields in schemas
[ https://issues.apache.org/jira/browse/SOLR-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-10177: Attachment: SOLR-10177.patch here's a patch that fixes up schema-inplace-updates.xml and it's associated test classes to leverage the simplified randomization added in SOLR-10864 > Consolidate randomized usage of PointFields in schemas > -- > > Key: SOLR-10177 > URL: https://issues.apache.org/jira/browse/SOLR-10177 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Assignee: Hoss Man > Attachments: SOLR-10177.patch > > > schema-inplace-updates.xml use per fieldType point fields randomization, > whereas other some schemas use per-field. However, the variable name is > similar and should be revisited and standardized across our tests. > Discussions here > https://issues.apache.org/jira/browse/SOLR-5944?focusedCommentId=15875108&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15875108. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10921) Make boolean query clause limit configurable per-query
[ https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060392#comment-16060392 ] Yonik Seeley commented on SOLR-10921: - bq. One potential workaround is to also call BooleanQuery.setMaxClauseCount in the constructor for a SolrConfig object as well Ok, I implemented that workaround, and it appears to work (at least the first couple of test failures didn't have any trace of max clause wonkiness). > Make boolean query clause limit configurable per-query > -- > > Key: SOLR-10921 > URL: https://issues.apache.org/jira/browse/SOLR-10921 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0) > > Attachments: SOLR-10921.patch, SOLR-10921.patch > > > This is the Solr version of LUCENE-7880 > Background: The removal of the arbitrary maxBooleanClauses has been blocked > in SOLR-4586, and there were objections to adding the ability to override > maxBooleanClauses at the Lucene level in LUCENE-7880. > That leaves us with this last option of implementing the check in solr by > raising the lucene limit and then using the maxBooleanClauses from > solrconfig.xml to throw an exception when the limit is exceeded. Solr > QParsers have access to the request object, which knows the > schema/core/config. This should fix the last-core-wins behavior due to the > lucene limit being a static. > Although this enables controlling the limit on a per-query basis, this issue > is not about adding any user API to do so. The capability will only be used > to make the current Solr maxBooleanClauses setting truly per-solr-core rather > than last-core-wins. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10921) Make boolean query clause limit configurable per-query
[ https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060391#comment-16060391 ] ASF subversion and git services commented on SOLR-10921: Commit 78731ea8f4b7bd91bbd5b4fb442cc423b4caee79 in lucene-solr's branch refs/heads/master from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=78731ea ] SOLR-10921: set setMaxClauseCount for every SolrConfig creation to work around test framework issues > Make boolean query clause limit configurable per-query > -- > > Key: SOLR-10921 > URL: https://issues.apache.org/jira/browse/SOLR-10921 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0) > > Attachments: SOLR-10921.patch, SOLR-10921.patch > > > This is the Solr version of LUCENE-7880 > Background: The removal of the arbitrary maxBooleanClauses has been blocked > in SOLR-4586, and there were objections to adding the ability to override > maxBooleanClauses at the Lucene level in LUCENE-7880. > That leaves us with this last option of implementing the check in solr by > raising the lucene limit and then using the maxBooleanClauses from > solrconfig.xml to throw an exception when the limit is exceeded. Solr > QParsers have access to the request object, which knows the > schema/core/config. This should fix the last-core-wins behavior due to the > lucene limit being a static. > Although this enables controlling the limit on a per-query basis, this issue > is not about adding any user API to do so. The capability will only be used > to make the current Solr maxBooleanClauses setting truly per-solr-core rather > than last-core-wins. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+173) - Build # 6671 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6671/ Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi Error Message: Error from server at http://127.0.0.1:56821/solr: java.nio.file.InvalidPathException: Illegal char <�> at index 53: C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr�uildsolr-core estJ1 empsolr.handler.V2ApiIntegrationTest_6B5B6BD69F3FC0E8-001 empDir-002 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: Error from server at http://127.0.0.1:56821/solr: java.nio.file.InvalidPathException: Illegal char <�> at index 53: C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr�uildsolr-core estJ1 empsolr.handler.V2ApiIntegrationTest_6B5B6BD69F3FC0E8-001 empDir-002 at __randomizedtesting.SeedInfo.seed([6B5B6BD69F3FC0E8:B7C58C572726A456]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:788) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:583) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:222) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:460) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:390) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1135) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:876) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi(V2ApiIntegrationTest.java:141) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evalua
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+173) - Build # 19941 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19941/ Java: 32bit/jdk-9-ea+173 -client -XX:+UseParallelGC 6 tests failed. FAILED: org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration Error Message: expected: but was: Stack Trace: org.junit.ComparisonFailure: expected: but was: at __randomizedtesting.SeedInfo.seed([DF3489F270B48BE4:61BFEF5D09CE85D1]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration(ClusterStateUpdateTest.java:104) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=4649, name=cdcr-update-log-synchronizer-2031-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest]
[jira] [Commented] (SOLR-10921) Make boolean query clause limit configurable per-query
[ https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060358#comment-16060358 ] Yonik Seeley commented on SOLR-10921: - My guess is that it's TestRuleSetupAndRestoreInstanceEnv. It's hard to test potential fixes because "ant test" fails on other tests all the time right now ;-) I don't know if there is a way to tell the test framework that we don't need/want TestRuleSetupAndRestoreInstanceEnv for the solr tests. One potential workaround is to also call BooleanQuery.setMaxClauseCount in the constructor for a SolrConfig object as well (right now it's static initialization.). Hopefully that will stomp it again before any tests that rely on it run. We can't just hack it in SolrTestCase because then we aren't testing reality (i.e. we could break it and never know). > Make boolean query clause limit configurable per-query > -- > > Key: SOLR-10921 > URL: https://issues.apache.org/jira/browse/SOLR-10921 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0) > > Attachments: SOLR-10921.patch, SOLR-10921.patch > > > This is the Solr version of LUCENE-7880 > Background: The removal of the arbitrary maxBooleanClauses has been blocked > in SOLR-4586, and there were objections to adding the ability to override > maxBooleanClauses at the Lucene level in LUCENE-7880. > That leaves us with this last option of implementing the check in solr by > raising the lucene limit and then using the maxBooleanClauses from > solrconfig.xml to throw an exception when the limit is exceeded. Solr > QParsers have access to the request object, which knows the > schema/core/config. This should fix the last-core-wins behavior due to the > lucene limit being a static. > Although this enables controlling the limit on a per-query basis, this issue > is not about adding any user API to do so. The capability will only be used > to make the current Solr maxBooleanClauses setting truly per-solr-core rather > than last-core-wins. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10935) BALANCESHARDUNIQUE does not distribute properties correctly
[ https://issues.apache.org/jira/browse/SOLR-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060345#comment-16060345 ] Daisy.Yuan commented on SOLR-10935: --- Why BALANCESHARDUNIQUE will be removed？Is there any other method to replace the BALANCESHARDUNIQUE API? > BALANCESHARDUNIQUE does not distribute properties correctly > --- > > Key: SOLR-10935 > URL: https://issues.apache.org/jira/browse/SOLR-10935 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 6.2 >Reporter: Daisy.Yuan > > Create a collection of 8 slices on 4 nodes, 2 replicas of each slice. > Node IP is: > 192.168.182.246:21101 > 192.168.182.247:21104 > 192.168.182.248:21101 > 192.168.182.149:21104 > After executing the BALANCESHARDUNIQUE command, the leader node is balanced > as follows: > Cloud Graph (* Leader) > shard1 |- * 192.168.182.248:21101 > |- 192.168.182.247.21104 > shard2 |- * 192.168.182.249:21104 > |- 192.168.182.246:21101 > shard3 |- 192.168.182.247:21104 > |- * 192.168.182.246:21101 > shard4 |- 192.168.182.248:21101 > |- * 192.168.182.249:21104 > shard5 |- 192.168.182.249:21104 > |- * 192.168.182.246:21101 > shard6 |- * 192.168.182.248:21101 > |- 192.168.182.247:21104 > shard7 |- 192.168.182.248:21101 > |- * 192.168.182.249:21104 > shard8 |- * 192.168.182.247:21104 > |- 192.168.182.246:21101 > The correct expected result should be that there are two leader on each node. > But the actual result is.. > there are 3 leaders on 192.168.182.249:21104, > and only one Leader on 192.168.182.247:21104 > the others are distributed correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)
[ https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060217#comment-16060217 ] Cao Manh Dat edited comment on SOLR-9989 at 6/23/17 2:49 AM: - [~ysee...@gmail.com] no, it is my mistake. Will fix the problem now. was (Author: caomanhdat): [~ysee...@gmail.com] not, it is my mistake. Will fix the problem now. > Add support for PointFields in FacetModule (JSON Facets) > > > Key: SOLR-9989 > URL: https://issues.apache.org/jira/browse/SOLR-9989 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Tomás Fernández Löbbe >Assignee: Cao Manh Dat > Fix For: master (7.0) > > Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch > > > Followup task of SOLR-8396 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 917 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/917/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest Error Message: Captured an uncaught exception in thread: Thread[id=23171, name=WRITER20, state=RUNNABLE, group=TGRP-TestStressInPlaceUpdates] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=23171, name=WRITER20, state=RUNNABLE, group=TGRP-TestStressInPlaceUpdates] Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:37290/qlwqv/collection1 at __randomizedtesting.SeedInfo.seed([D3C981FEEFC9C857]:0) at org.apache.solr.cloud.TestStressInPlaceUpdates$1.run(TestStressInPlaceUpdates.java:320) Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:37290/qlwqv/collection1 at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:605) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177) at org.apache.solr.cloud.TestStressInPlaceUpdates.addDocAndGetVersion(TestStressInPlaceUpdates.java:563) at org.apache.solr.cloud.TestStressInPlaceUpdates$1.run(TestStressInPlaceUpdates.java:285) Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160) at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84) at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251) at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:497) ... 6 more Build Log: [...truncated 12731 lines...] [junit4] Suite: org.apache.solr.cloud.TestStressInPlaceUpdates [junit4] 2> Creating dataDir: /export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.TestStressInPlaceUpdates_D3C981FEEFC9C857-001/init-core-data-001 [junit4] 2> 1993679 WARN (SUITE-TestStressInPlaceUpdates-seed#[D3C981FEEFC9C857]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=146 numCloses=146 [junit4] 2> 1993679 INFO (SUITE-TestStressInPlaceUpdates-seed#[D3C981FEEFC9C857]-worker) [] o.a.s.SolrTestCaseJ4 Using TrieFields [junit4] 2> 1993680 INFO (SUITE-TestStressInPlaceUpdates-seed#[D3C981FEEFC9C857]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN) [junit4] 2> 1993681 INFO (SUITE-TestStressInPlaceUpdates-seed#[D3C981FEEFC9C857]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /qlwqv/ [junit4] 2> 1993681 INFO
[jira] [Commented] (SOLR-10921) Make boolean query clause limit configurable per-query
[ https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060324#comment-16060324 ] Erick Erickson commented on SOLR-10921: --- random guess: the static in Lucene is somehow getting involved? > Make boolean query clause limit configurable per-query > -- > > Key: SOLR-10921 > URL: https://issues.apache.org/jira/browse/SOLR-10921 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0) > > Attachments: SOLR-10921.patch, SOLR-10921.patch > > > This is the Solr version of LUCENE-7880 > Background: The removal of the arbitrary maxBooleanClauses has been blocked > in SOLR-4586, and there were objections to adding the ability to override > maxBooleanClauses at the Lucene level in LUCENE-7880. > That leaves us with this last option of implementing the check in solr by > raising the lucene limit and then using the maxBooleanClauses from > solrconfig.xml to throw an exception when the limit is exceeded. Solr > QParsers have access to the request object, which knows the > schema/core/config. This should fix the last-core-wins behavior due to the > lucene limit being a static. > Although this enables controlling the limit on a per-query basis, this issue > is not about adding any user API to do so. The capability will only be used > to make the current Solr maxBooleanClauses setting truly per-solr-core rather > than last-core-wins. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10496) Implement ComputePlanAction for autoscaling
[ https://issues.apache.org/jira/browse/SOLR-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060317#comment-16060317 ] ASF subversion and git services commented on SOLR-10496: Commit 70f60a23bc1e706abb41a4900c65305f1763f8f6 in lucene-solr's branch refs/heads/jira/SOLR-10496 from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=70f60a2 ] SOLR-10496: Remove debugging info from tests. Enable recursive suggestion of operations. > Implement ComputePlanAction for autoscaling > --- > > Key: SOLR-10496 > URL: https://issues.apache.org/jira/browse/SOLR-10496 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: autoscaling > Fix For: master (7.0) > > Attachments: SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch > > > The ComputePlanAction will use the cluster/collection policy to calculate the > cluster operations to be performed. This issue is about integrating the work > done in SOLR-10278 with the trigger framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10935) BALANCESHARDUNIQUE does not distribute properties correctly
[ https://issues.apache.org/jira/browse/SOLR-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daisy.Yuan updated SOLR-10935: -- Description: Create a collection of 8 slices on 4 nodes, 2 replicas of each slice. Node IP is: 192.168.182.246:21101 192.168.182.247:21104 192.168.182.248:21101 192.168.182.149:21104 After executing the BALANCESHARDUNIQUE command, the leader node is balanced as follows: Cloud Graph (* Leader) shard1 |- * 192.168.182.248:21101 |- 192.168.182.247.21104 shard2 |- * 192.168.182.249:21104 |- 192.168.182.246:21101 shard3 |- 192.168.182.247:21104 |- * 192.168.182.246:21101 shard4 |- 192.168.182.248:21101 |- * 192.168.182.249:21104 shard5 |- 192.168.182.249:21104 |- * 192.168.182.246:21101 shard6 |- * 192.168.182.248:21101 |- 192.168.182.247:21104 shard7 |- 192.168.182.248:21101 |- * 192.168.182.249:21104 shard8 |- * 192.168.182.247:21104 |- 192.168.182.246:21101 The correct expected result should be that there are two leader on each node. But the actual result is.. there are 3 leaders on 192.168.182.249:21104, and only one Leader on 192.168.182.247:21104 the others are distributed correctly. was: Create a collection of 8 slices on 4 nodes, 2 replicas of each slice. Node IP is: 192.168.182.246:21101 192.168.182.247:21104 192.168.182.248:21101 192.168.182.149:21104 After executing the BALANCESHARDUNIQUE command, the leader node is balanced as follows: Shard1 192.168.182.248:21101 Shard2 192.168.182.249:21104 Shard3 192.168.182.246:21101 Shard4 192.168.182.249:21104 Shard5 192.168.182.246:21101 Shard6 192.168.182.248:21101 Shard7 192.168.182.249:21104 Shard8 192.168.182.247:21104 The correct expected result should be that there are two leader on each node. But the actual result is.. there are 3 leaders on 192.168.182.249:21104, and only one Leader on 192.168.182.247:21104 the others are distributed correctly. > BALANCESHARDUNIQUE does not distribute properties correctly > --- > > Key: SOLR-10935 > URL: https://issues.apache.org/jira/browse/SOLR-10935 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 6.2 >Reporter: Daisy.Yuan > > Create a collection of 8 slices on 4 nodes, 2 replicas of each slice. > Node IP is: > 192.168.182.246:21101 > 192.168.182.247:21104 > 192.168.182.248:21101 > 192.168.182.149:21104 > After executing the BALANCESHARDUNIQUE command, the leader node is balanced > as follows: > Cloud Graph (* Leader) > shard1 |- * 192.168.182.248:21101 > |- 192.168.182.247.21104 > shard2 |- * 192.168.182.249:21104 > |- 192.168.182.246:21101 > shard3 |- 192.168.182.247:21104 > |- * 192.168.182.246:21101 > shard4 |- 192.168.182.248:21101 > |- * 192.168.182.249:21104 > shard5 |- 192.168.182.249:21104 > |- * 192.168.182.246:21101 > shard6 |- * 192.168.182.248:21101 > |- 192.168.182.247:21104 > shard7 |- 192.168.182.248:21101 > |- * 192.168.182.249:21104 > shard8 |- * 192.168.182.247:21104 > |- 192.168.182.246:21101 > The correct expected result should be that there are two leader on each node. > But the actual result is.. > there are 3 leaders on 192.168.182.249:21104, > and only one Leader on 192.168.182.247:21104 > the others are distributed correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1391 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1391/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery Error Message: Path not found: /responseHeader/status Stack Trace: java.lang.RuntimeException: Path not found: /responseHeader/status at __randomizedtesting.SeedInfo.seed([7A90AB8B315CBA8B:F9D6B9721467C5E]:0) at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329) at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271) at org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286) at org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184) at org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138) at org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.te
[jira] [Comment Edited] (SOLR-10921) Make boolean query clause limit configurable per-query
[
https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060272#comment-16060272
]
Yonik Seeley edited comment on SOLR-10921 at 6/23/17 1:10 AM:
--
Hmmm, interesting. This is a failure in this line:
assertTrue(e.getMessage().contains("many clauses"));
So the exception was thrown for exceeding max clauses as expected, but the
exception message didn't contain the expected text.
It looks like SolrQueryParserBase caught Lucene's TooManyClauses exception
(which should never happen now... QueryUtils throws SolrException).
So I think it's probably this bug again (a test-framework bug):
https://issues.apache.org/jira/browse/SOLR-4586?focusedCommentId=14202115&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14202115
I don't think I've ever seen this issue running an individual test case
either... it must be some issue when running everything.
was (Author: ysee...@gmail.com):
Hmmm, interesting. This is a failure in this line:
assertTrue(e.getMessage().contains("many clauses"));
So the exception was thrown for exceeding max clauses as expected, but the
exception message didn't contain the expected text.
It looks like SolrQueryParserBase caught Lucene's TooManyClauses exception
(which should never happen now... QueryUtils throws SolrException).
So I think it's probably this bug again (a test-framework bug):
https://issues.apache.org/jira/browse/SOLR-4586?focusedCommentId=14202115&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14202115
> Make boolean query clause limit configurable per-query
> --
>
> Key: SOLR-10921
> URL: https://issues.apache.org/jira/browse/SOLR-10921
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10921.patch, SOLR-10921.patch
>
>
> This is the Solr version of LUCENE-7880
> Background: The removal of the arbitrary maxBooleanClauses has been blocked
> in SOLR-4586, and there were objections to adding the ability to override
> maxBooleanClauses at the Lucene level in LUCENE-7880.
> That leaves us with this last option of implementing the check in solr by
> raising the lucene limit and then using the maxBooleanClauses from
> solrconfig.xml to throw an exception when the limit is exceeded. Solr
> QParsers have access to the request object, which knows the
> schema/core/config. This should fix the last-core-wins behavior due to the
> lucene limit being a static.
> Although this enables controlling the limit on a per-query basis, this issue
> is not about adding any user API to do so. The capability will only be used
> to make the current Solr maxBooleanClauses setting truly per-solr-core rather
> than last-core-wins.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10921) Make boolean query clause limit configurable per-query
[
https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060272#comment-16060272
]
Yonik Seeley commented on SOLR-10921:
-
Hmmm, interesting. This is a failure in this line:
assertTrue(e.getMessage().contains("many clauses"));
So the exception was thrown for exceeding max clauses as expected, but the
exception message didn't contain the expected text.
It looks like SolrQueryParserBase caught Lucene's TooManyClauses exception
(which should never happen now... QueryUtils throws SolrException).
So I think it's probably this bug again (a test-framework bug):
https://issues.apache.org/jira/browse/SOLR-4586?focusedCommentId=14202115&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14202115
> Make boolean query clause limit configurable per-query
> --
>
> Key: SOLR-10921
> URL: https://issues.apache.org/jira/browse/SOLR-10921
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10921.patch, SOLR-10921.patch
>
>
> This is the Solr version of LUCENE-7880
> Background: The removal of the arbitrary maxBooleanClauses has been blocked
> in SOLR-4586, and there were objections to adding the ability to override
> maxBooleanClauses at the Lucene level in LUCENE-7880.
> That leaves us with this last option of implementing the check in solr by
> raising the lucene limit and then using the maxBooleanClauses from
> solrconfig.xml to throw an exception when the limit is exceeded. Solr
> QParsers have access to the request object, which knows the
> schema/core/config. This should fix the last-core-wins behavior due to the
> lucene limit being a static.
> Although this enables controlling the limit on a per-query basis, this issue
> is not about adding any user API to do so. The capability will only be used
> to make the current Solr maxBooleanClauses setting truly per-solr-core rather
> than last-core-wins.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10938) SuppressPointFields should require a bugUrl
[ https://issues.apache.org/jira/browse/SOLR-10938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-10938. - Resolution: Fixed Assignee: Hoss Man > SuppressPointFields should require a bugUrl > --- > > Key: SOLR-10938 > URL: https://issues.apache.org/jira/browse/SOLR-10938 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: master (7.0) > > > the SuppressPointFields annotation currently leaves bugUrl as an optional > attribute -- we should make it required to ensure no one disables points on a > test w/o having a a known open jira tracking the underlying problem -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 1894 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1894/ 7 tests failed. FAILED: org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration Error Message: expected: but was: Stack Trace: org.junit.ComparisonFailure: expected: but was: at __randomizedtesting.SeedInfo.seed([97354ED717CB430B:29BE28786EB14D3E]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration(ClusterStateUpdateTest.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=2596, name=testExecutor-1261-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=2596
[jira] [Commented] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[ https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060255#comment-16060255 ] Hoss Man commented on SOLR-10503: - +1 > CurrencyField should be changed from TrieLongField to LongPointField for > underlying raw-polyfield > - > > Key: SOLR-10503 > URL: https://issues.apache.org/jira/browse/SOLR-10503 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > Attachments: SOLR-10503.patch, SOLR-10503.patch, SOLR-10503.patch, > SOLR-10503.patch, SOLR-10503.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19940 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19940/ Java: 32bit/jdk1.8.0_131 -server -XX:+UseParallelGC 11 tests failed. FAILED: org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration Error Message: expected: but was: Stack Trace: org.junit.ComparisonFailure: expected: but was: at __randomizedtesting.SeedInfo.seed([D0B0F5C2B535A6D3:6E3B936DCC4FA8E6]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration(ClusterStateUpdateTest.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=9653, name=testExecutor-4011-thread-11, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError:
[jira] [Updated] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[
https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-10503:
--
Attachment: SOLR-10503.patch
{quote}
bq. ... I had to introduce a boolean configuredSubFieldSuffixes (name suggested
by you earlier) ...
As things stand now, can't we eliminate that variable and just do...
{quote}
Yes, that works, thanks. Patch attached.
> CurrencyField should be changed from TrieLongField to LongPointField for
> underlying raw-polyfield
> -
>
> Key: SOLR-10503
> URL: https://issues.apache.org/jira/browse/SOLR-10503
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-10503.patch, SOLR-10503.patch, SOLR-10503.patch,
> SOLR-10503.patch, SOLR-10503.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[
https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060239#comment-16060239
]
Hoss Man commented on SOLR-10503:
-
bq. ... I had to introduce a boolean configuredSubFieldSuffixes (name
suggested by you earlier) ...
Hmm, that suggestion was made in the context of "Even if I'm in the minority
and most folks don't like the idea of requiring users to configure..." -- ie:
if that single class needed to support both configurable suffixes and implicit
suffixes.
As things stand now, can't we eliminate that variable and just do...
{code}
public void inform(IndexSchema schema) {
this.schema = schema;
if (null == fieldTypeAmountRaw) {
assert null != fieldSuffixAmountRaw : "How did we get here?";
SchemaField field = schema.getFieldOrNull(POLY_FIELD_SEPARATOR +
fieldSuffixAmountRaw);
if (field == null) {
throw new SolrException(ErrorCode.SERVER_ERROR, "Field type \"" +
this.getTypeName()
+ "\": Undefined dynamic field for " +
PARAM_FIELD_SUFFIX_AMOUNT_RAW + "=\"" + fieldSuffixAmountRaw + "\"");
}
fieldTypeAmountRaw = field.getType();
if (!(fieldTypeAmountRaw instanceof LongValueFieldType)) {
throw new SolrException(ErrorCode.SERVER_ERROR, "Field type \"" +
this.getTypeName()
+ "\": Dynamic field for " + PARAM_FIELD_SUFFIX_AMOUNT_RAW + "=\""
+ fieldSuffixAmountRaw
+ "\" must have type class extending LongValueFieldType");
}
}
if (null == fieldTypeCurrency) {
assert null != fieldSuffixCurrency : "How did we get here?";
SchemaField field = schema.getFieldOrNull(POLY_FIELD_SEPARATOR +
fieldSuffixCurrency);
if (field == null) {
throw new SolrException(ErrorCode.SERVER_ERROR, "Field type \"" +
this.getTypeName()
+ "\": Undefined dynamic field for " + PARAM_FIELD_SUFFIX_CURRENCY
+ "=\"" + fieldSuffixCurrency + "\"");
}
fieldTypeCurrency = field.getType();
if (!(fieldTypeCurrency instanceof StrField)) {
throw new SolrException(ErrorCode.SERVER_ERROR, "Field type \"" +
this.getTypeName()
+ "\": Dynamic field for " + PARAM_FIELD_SUFFIX_CURRENCY + "=\"" +
fieldSuffixCurrency
+ "\" must have type class of (or extending) StrField");
}
}
}
{code}
?
> CurrencyField should be changed from TrieLongField to LongPointField for
> underlying raw-polyfield
> -
>
> Key: SOLR-10503
> URL: https://issues.apache.org/jira/browse/SOLR-10503
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-10503.patch, SOLR-10503.patch, SOLR-10503.patch,
> SOLR-10503.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 956 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/956/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.solr.cloud.LeaderFailureAfterFreshStartTest.test Error Message: java.io.IOException: Couldn't instantiate org.apache.zookeeper.ClientCnxnSocketNIO Stack Trace: org.apache.solr.common.SolrException: java.io.IOException: Couldn't instantiate org.apache.zookeeper.ClientCnxnSocketNIO at __randomizedtesting.SeedInfo.seed([5FB3F6BA35A9CE04:D7E7C9609B55A3FC]:0) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:171) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:117) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:112) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:99) at org.apache.solr.cloud.AbstractDistribZkTestBase.printLayout(AbstractDistribZkTestBase.java:322) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribTearDown(AbstractFullDistribZkTestBase.java:1500) at org.apache.solr.cloud.LeaderFailureAfterFreshStartTest.distribTearDown(LeaderFailureAfterFreshStartTest.java:76) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:969) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.io.IOException: Couldn't instantiate org.apache.zookeeper.ClientCnxnSocketNIO at org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:1842) at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:447) at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)
[ https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060226#comment-16060226 ] ASF subversion and git services commented on SOLR-9989: --- Commit 6aec01e426402937d05ca92442acb54e2cde9b79 in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6aec01e ] SOLR-9989: Enable generic testing for other facet methods > Add support for PointFields in FacetModule (JSON Facets) > > > Key: SOLR-9989 > URL: https://issues.apache.org/jira/browse/SOLR-9989 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Tomás Fernández Löbbe >Assignee: Cao Manh Dat > Fix For: master (7.0) > > Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch > > > Followup task of SOLR-8396 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[
https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060213#comment-16060213
]
Steve Rowe edited comment on SOLR-10503 at 6/23/17 12:04 AM:
-
Patch folding in [~hossman]'s latest feedback.
Comments inline below:
{quote}
bq. I made them static inner classes, but as a result had to add exceptional
classloader logic to load CurrencyFieldType inner classes (currently only
FileExchangeRateProvider).
Oh ... uck ... i'm sorry, i hadn't even thought about that – I was just trying
to avoid "polluting" the schema package with what felt like implementation
details, I didn't even think about the fact that those classes can be
configured by name... Please ignore that suggestion and go back to the simpler
code you had before unless you think this is better for some reason.
{quote}
I left {{CurrencyValue}} as an inner class, moved {{FileExchangeRateProvider}}
out to its own .java file, and removed the exception classloader logic.
{quote}
bq. I've made this change. I think the user experience would be better with
defaults for the majority of folks who I'm guessing won't care about sub-field
details. But I'm ok with not providing them.
My take is that I'd rather we provide those "defaults" in our sample configsets
where they are more obvious to users who want to tweak them, and we can
trivially change them overtime w/o breaking backcompat for users who upgrade
w/their existing configs – having "defaults in code" are much harder for us to
change.
{quote}
Good arguments.
bq. why do we need MethodHandles.lookup() in CurrencyFieldType.init and
checkSchemaField – wouldn't this.getClass() work just as well?
We don't. I replaced them with {{getClass()}}.
bq. CurrencyField.inform(IndexSchema) should be calling super.inform() as it's
last step (and as a result doesn't need to explicitly assign this.schema
Done. I had to introduce a boolean {{configuredSubFieldSuffixes}} (name
suggested by you earlier) to avoid calling the dynamic field validation in
{{CurrencyFieldType.inform()}} when called from {{CurrencyField.inform()}} via
{{super.inform()}}.
was (Author: steve_rowe):
Patch folding in [~hossman]'s latest feedback.
Comments inline below:
{quote}
bq. I made them static inner classes, but as a result had to add exceptional
classloader logic to load CurrencyFieldType inner classes (currently only
FileExchangeRateProvider).
Oh ... uck ... i'm sorry, i hadn't even thought about that – I was just trying
to avoid "polluting" the schema package with what felt like implementation
details, I didn't even think about the fact that those classes can be
configured by name... Please ignore that suggestion and go back to the simpler
code you had before unless you think this is better for some reason.
{quote}
{quote}
bq. I've made this change. I think the user experience would be better with
defaults for the majority of folks who I'm guessing won't care about sub-field
details. But I'm ok with not providing them.
My take is that I'd rather we provide those "defaults" in our sample configsets
where they are more obvious to users who want to tweak them, and we can
trivially change them overtime w/o breaking backcompat for users who upgrade
w/their existing configs – having "defaults in code" are much harder for us to
change.
{quote}
Good arguments.
bq. why do we need MethodHandles.lookup() in CurrencyFieldType.init and
checkSchemaField – wouldn't this.getClass() work just as well?
We don't. I replaced them with getClass().
bq. CurrencyField.inform(IndexSchema) should be calling super.inform() as it's
last step (and as a result doesn't need to explicitly assign this.schema
Done. I had to introduce a boolean {{configuredSubFieldSuffixes}} (name
suggested by you earlier) to avoid calling the dynamic field validation in
{{CurrencyFieldType.inform()}} when called from {{CurrencyField.inform()}} via
{{super.inform()}}.
> CurrencyField should be changed from TrieLongField to LongPointField for
> underlying raw-polyfield
> -
>
> Key: SOLR-10503
> URL: https://issues.apache.org/jira/browse/SOLR-10503
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-10503.patch, SOLR-10503.patch, SOLR-10503.patch,
> SOLR-10503.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10938) SuppressPointFields should require a bugUrl
[ https://issues.apache.org/jira/browse/SOLR-10938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060216#comment-16060216 ] ASF subversion and git services commented on SOLR-10938: Commit 01b7e315661275bef213103b1bbebe76258897db in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=01b7e31 ] SOLR-10938 @SuppressPointFields now requires bugUrl > SuppressPointFields should require a bugUrl > --- > > Key: SOLR-10938 > URL: https://issues.apache.org/jira/browse/SOLR-10938 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > Fix For: master (7.0) > > > the SuppressPointFields annotation currently leaves bugUrl as an optional > attribute -- we should make it required to ensure no one disables points on a > test w/o having a a known open jira tracking the underlying problem -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)
[ https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060217#comment-16060217 ] Cao Manh Dat commented on SOLR-9989: [~ysee...@gmail.com] not, it is my mistake. Will fix the problem now. > Add support for PointFields in FacetModule (JSON Facets) > > > Key: SOLR-9989 > URL: https://issues.apache.org/jira/browse/SOLR-9989 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Tomás Fernández Löbbe >Assignee: Cao Manh Dat > Fix For: master (7.0) > > Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch > > > Followup task of SOLR-8396 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10847) TermsComponent doesn't work with Points fields - confusing errors when using terms.list
[ https://issues.apache.org/jira/browse/SOLR-10847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060214#comment-16060214 ] ASF subversion and git services commented on SOLR-10847: Commit 49e9b68c2985987eeeabfdaa418f6021bd6be389 in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49e9b68 ] SOLR-10847: add jira URL to existing @SuppressPointFields annotation > TermsComponent doesn't work with Points fields - confusing errors when using > terms.list > --- > > Key: SOLR-10847 > URL: https://issues.apache.org/jira/browse/SOLR-10847 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > > TermsComponent doesn't work if the field in question is "Points" based > (because the field won't have any Terms) > Given the nature of TermsComponent, maybe this is fine? but it should > probably throw an error in this case instead of silently returning nothing by > default (current behavior) and throwing an UnSupOpEx if "terms.list" is > specified. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)
[ https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060215#comment-16060215 ] ASF subversion and git services commented on SOLR-9989: --- Commit 7a9f9b0be02fa31a9647bb4b1e74d8569b08 in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7a9f9b0 ] SOLR-9989: remove @SuppressPointFields annotation now that JSON facets work with numeric points+docvalues > Add support for PointFields in FacetModule (JSON Facets) > > > Key: SOLR-9989 > URL: https://issues.apache.org/jira/browse/SOLR-9989 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Tomás Fernández Löbbe >Assignee: Cao Manh Dat > Fix For: master (7.0) > > Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch > > > Followup task of SOLR-8396 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[
https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-10503:
--
Attachment: SOLR-10503.patch
Patch folding in [~hossman]'s latest feedback.
Comments inline below:
{quote}
bq. I made them static inner classes, but as a result had to add exceptional
classloader logic to load CurrencyFieldType inner classes (currently only
FileExchangeRateProvider).
Oh ... uck ... i'm sorry, i hadn't even thought about that – I was just trying
to avoid "polluting" the schema package with what felt like implementation
details, I didn't even think about the fact that those classes can be
configured by name... Please ignore that suggestion and go back to the simpler
code you had before unless you think this is better for some reason.
{quote}
{quote}
bq. I've made this change. I think the user experience would be better with
defaults for the majority of folks who I'm guessing won't care about sub-field
details. But I'm ok with not providing them.
My take is that I'd rather we provide those "defaults" in our sample configsets
where they are more obvious to users who want to tweak them, and we can
trivially change them overtime w/o breaking backcompat for users who upgrade
w/their existing configs – having "defaults in code" are much harder for us to
change.
{quote}
Good arguments.
bq. why do we need MethodHandles.lookup() in CurrencyFieldType.init and
checkSchemaField – wouldn't this.getClass() work just as well?
We don't. I replaced them with getClass().
bq. CurrencyField.inform(IndexSchema) should be calling super.inform() as it's
last step (and as a result doesn't need to explicitly assign this.schema
Done. I had to introduce a boolean {{configuredSubFieldSuffixes}} (name
suggested by you earlier) to avoid calling the dynamic field validation in
{{CurrencyFieldType.inform()}} when called from {{CurrencyField.inform()}} via
{{super.inform()}}.
> CurrencyField should be changed from TrieLongField to LongPointField for
> underlying raw-polyfield
> -
>
> Key: SOLR-10503
> URL: https://issues.apache.org/jira/browse/SOLR-10503
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-10503.patch, SOLR-10503.patch, SOLR-10503.patch,
> SOLR-10503.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)
[
https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060210#comment-16060210
]
Yonik Seeley commented on SOLR-9989:
Hmmm, wait... this patch seemed to remove the generic testing of other facet
methods that [~dsmiley] added. Was that intentional?
{code}
@@ -87,7 +85,9 @@ public class TestJsonFacets extends SolrTestCaseHS {
@ParametersFactory
public static Iterable parameters() {
// wrap each enum val in an Object[] and return as Iterable
-return () -> Arrays.stream(FacetField.FacetMethod.values()).map(it -> new
Object[]{it}).iterator();
+return () -> Arrays.stream(FacetField.FacetMethod.values())
+.filter(m -> m == FacetField.FacetMethod.ENUM)
+.map(it -> new Object[]{it}).iterator();
}
{code}
> Add support for PointFields in FacetModule (JSON Facets)
>
>
> Key: SOLR-9989
> URL: https://issues.apache.org/jira/browse/SOLR-9989
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
>Reporter: Tomás Fernández Löbbe
>Assignee: Cao Manh Dat
> Fix For: master (7.0)
>
> Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch
>
>
> Followup task of SOLR-8396
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-10763: --- Fix Version/s: 6.7 > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla >Assignee: Jan Høydahl > Fix For: master (7.0), 6.7 > > Attachments: original UI.png, SOLR-10763.patch, SOLR-10763.patch, > solr-admin-replication-fixed.png, solr default console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10921) Make boolean query clause limit configurable per-query
[
https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060204#comment-16060204
]
Steve Rowe commented on SOLR-10921:
---
This doesn't reproduce for me but seems worthy of mention
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4096/]:
{noformat}
Checking out Revision ae01113472378093462e88b90e6e07a2cd863f8f
(refs/remotes/origin/master)
[...]
[junit4] 2> 1861432 ERROR
(TEST-TestSolrQueryParser.testManyClauses-seed#[48DB078C2CAE9CBD]) []
o.a.s.SolrTestCaseJ4 REQUEST FAILED:
q=id:(z0+z1+z2+z3+z4+z5+z6+z7+z8+z9+z10+z11+z12+z13+z14+z15+z16+z17+z18+z19+z20+z21+z22+z23+z24+z25+z26+z27+z28+z29+z30+z31+z32+z33+z34+z35+z36+z37+z38+z39+z40+z41+z42+z43+z44+z45+z46+z47+z48+z49+z50+z51+z52+z53+z54+z55+z56+z57+z58+z59+z60+z61+z62+z63+z64+z65+z66+z67+z68+z69+z70+z71+z72+z73+z74+z75+z76+z77+z78+z79+z80+z81+z82+z83+z84+z85+z86+z87+z88+z89+z90+z91+z92+z93+z94+z95+z96+z97+z98+z99+z100+z101+z102+z103+z104+z105+z106+z107+z108+z109+z110+z111+z112+z113+z114+z115+z116+z117+z118+z119+z120+z121+z122+z123+z124+z125+z126+z127+z128+z129+z130+z131+z132+z133+z134+z135+z136+z137+z138+z139+z140+z141+z142+z143+z144+z145+z146+z147+z148+z149+z150+z151+z152+z153+z154+z155+z156+z157+z158+z159+z160+z161+z162+z163+z164+z165+z166+z167+z168+z169+z170+z171+z172+z173+z174+z175+z176+z177+z178+z179+z180+z181+z182+z183+z184+z185+z186+z187+z188+z189+z190+z191+z192+z193+z194+z195+z196+z197+z198+z199+z200+z201+z202+z203+z204+z205+z206+z207+z208+z209+z210+z211+z212+z213+z214+z215+z216+z217+z218+z219+z220+z221+z222+z223+z224+z225+z226+z227+z228+z229+z230+z231+z232+z233+z234+z235+z236+z237+z238+z239+z240+z241+z242+z243+z244+z245+z246+z247+z248+z249+z250+z251+z252+z253+z254+z255+z256+z257+z258+z259+z260+z261+z262+z263+z264+z265+z266+z267+z268+z269+z270+z271+z272+z273+z274+z275+z276+z277+z278+z279+z280+z281+z282+z283+z284+z285+z286+z287+z288+z289+z290+z291+z292+z293+z294+z295+z296+z297+z298+z299+z300+z301+z302+z303+z304+z305+z306+z307+z308+z309+z310+z311+z312+z313+z314+z315+z316+z317+z318+z319+z320+z321+z322+z323+z324+z325+z326+z327+z328+z329+z330+z331+z332+z333+z334+z335+z336+z337+z338+z339+z340+z341+z342+z343+z344+z345+z346+z347+z348+z349+z350+z351+z352+z353+z354+z355+z356+z357+z358+z359+z360+z361+z362+z363+z364+z365+z366+z367+z368+z369+z370+z371+z372+z373+z374+z375+z376+z377+z378+z379+z380+z381+z382+z383+z384+z385+z386+z387+z388+z389+z390+z391+z392+z393+z394+z395+z396+z397+z398+z399+z400+z401+z402+z403+z404+z405+z406+z407+z408+z409+z410+z411+z412+z413+z414+z415+z416+z417+z418+z419+z420+z421+z422+z423+z424+z425+z426+z427+z428+z429+z430+z431+z432+z433+z434+z435+z436+z437+z438+z439+z440+z441+z442+z443+z444+z445+z446+z447+z448+z449+z450+z451+z452+z453+z454+z455+z456+z457+z458+z459+z460+z461+z462+z463+z464+z465+z466+z467+z468+z469+z470+z471+z472+z473+z474+z475+z476+z477+z478+z479+z480+z481+z482+z483+z484+z485+z486+z487+z488+z489+z490+z491+z492+z493+z494+z495+z496+z497+z498+z499+z500+z501+z502+z503+z504+z505+z506+z507+z508+z509+z510+z511+z512+z513+z514+z515+z516+z517+z518+z519+z520+z521+z522+z523+z524+z525+z526+z527+z528+z529+z530+z531+z532+z533+z534+z535+z536+z537+z538+z539+z540+z541+z542+z543+z544+z545+z546+z547+z548+z549+z550+z551+z552+z553+z554+z555+z556+z557+z558+z559+z560+z561+z562+z563+z564+z565+z566+z567+z568+z569+z570+z571+z572+z573+z574+z575+z576+z577+z578+z579+z580+z581+z582+z583+z584+z585+z586+z587+z588+z589+z590+z591+z592+z593+z594+z595+z596+z597+z598+z599+z600+z601+z602+z603+z604+z605+z606+z607+z608+z609+z610+z611+z612+z613+z614+z615+z616+z617+z618+z619+z620+z621+z622+z623+z624+z625+z626+z627+z628+z629+z630+z631+z632+z633+z634+z635+z636+z637+z638+z639+z640+z641+z642+z643+z644+z645+z646+z647+z648+z649+z650+z651+z652+z653+z654+z655+z656+z657+z658+z659+z660+z661+z662+z663+z664+z665+z666+z667+z668+z669+z670+z671+z672+z673+z674+z675+z676+z677+z678+z679+z680+z681+z682+z683+z684+z685+z686+z687+z688+z689+z690+z691+z692+z693+z694+z695+z696+z697+z698+z699+z700+z701+z702+z703+z704+z705+z706+z707+z708+z709+z710+z711+z712+z713+z714+z715+z716+z717+z718+z719+z720+z721+z722+z723+z724+z725+z726+z727+z728+z729+z730+z731+z732+z733+z734+z735+z736+z737+z738+z739+z740+z741+z742+z743+z744+z745+z746+z747+z748+z749+z750+z751+z752+z753+z754+z755+z756+z757+z758+z759+z760+z761+z762+z763+z764+z765+z766+z767+z768+z769+z770+z771+z772+z773+z774+z775+z776+z777+z778+z779+z780+z781+z782+z783+z784+z785+z786+z787+z788+z789+z790+z791+z792+z793+z794+z795+z796+z797+z798+z799+z800+z801+z802+z803+z804+z805+z806+z807+z808+z809+z810+z811+z812+z813+z814+z815+z816+z817+z818+z819+z820+z821+z822+z823+z824+z825+z826+z827+z828+z829+z830+z831+z832+z833+z834+z835+z836+z837+z838+z839+z840+z841+z842+z843+z844+z845+z846+z847+z848+z849+z850+z851+z852+z853+z854+z855+z856+z857+z858+z859+z860+z861+z862+z863+z864+z865+z866+z867+z868+z869+z870+z871+z872+z873+z874+z875+z876+z877+z878+z879+z880+z881+z882+z883+z884+z885+z886+z887+z888+z889+z890+z891+z892+z893+z89
[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3820 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3820/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseParallelGC
1 tests failed.
FAILED: org.apache.solr.core.TestDynamicLoading.testDynamicLoading
Error Message:
Could not get expected value
'org.apache.solr.core.BlobStoreTestRequestHandler' for path
'overlay/requestHandler/\/test1/class' full output: { "responseHeader":{
"status":0, "QTime":0}, "overlay":{ "znodeVersion":0,
"runtimeLib":{"colltest":{ "name":"colltest", "version":1,
from server: null
Stack Trace:
java.lang.AssertionError: Could not get expected value
'org.apache.solr.core.BlobStoreTestRequestHandler' for path
'overlay/requestHandler/\/test1/class' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"overlay":{
"znodeVersion":0,
"runtimeLib":{"colltest":{
"name":"colltest",
"version":1, from server: null
at
__randomizedtesting.SeedInfo.seed([ED836E63FFBF70D6:35CE43340862D576]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.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:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter
[jira] [Updated] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-10763: --- Attachment: SOLR-10763.patch Thanks Bojan. Attaching final patch. Will commit this tomorrow. > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla >Assignee: Jan Høydahl > Fix For: master (7.0) > > Attachments: original UI.png, SOLR-10763.patch, SOLR-10763.patch, > solr-admin-replication-fixed.png, solr default console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
BaseTokenStreamTestCase Custom Debug Output
Hey all, I wrote a small BaseTokenStreamTestCase, so when a test fails, it gives some useful debugging output explaining the token stream. Makes it pretty easy to get your tests / offsets configured properly. Any comments/ - is BaseTokenStreamTestCase the right place to add this utility logic to? testFailedCase(com.lucidworks.analysis.TestAutoPhrasingTokenFilter) Time elapsed: 0.023 s <<< FAILURE! java.lang.AssertionError: -- View this message in context: http://lucene.472066.n3.nabble.com/BaseTokenStreamTestCase-Custom-Debug-Output-tp4342451.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-6.x - Build # 952 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/952/ 1 tests failed. FAILED: org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateSearchDelete Error Message: Error from server at http://127.0.0.1:53497/solr: Could not fully remove collection: testcollection Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:53497/solr: Could not fully remove collection: testcollection at __randomizedtesting.SeedInfo.seed([3D93D264FFF74609:9E697CC1781FACAC]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:594) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:477) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:407) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1383) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177) at org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateSearchDelete(TestMiniSolrCloudCluster.java:212) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapte
[jira] [Comment Edited] (SOLR-10763) Admin Console error in solr 6.5
[
https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060179#comment-16060179
]
Bojan Vitnik edited comment on SOLR-10763 at 6/22/17 11:20 PM:
---
OK. It was a quick find in the end. On line 107 we have:
{code:java}
107: var matchingIterations = find(iterations, failedDate);
{code}
Function "find" was returning an empty (zero length) array of iterations so
line 108 should be like this:
{code:java}
108: if (matchingIterations[0]) {
{code}
and not like this:
{code:java}
108: if (matchingIterations) {
{code}
if(matchingIterations) will always be true even when array is empty but on line
109:
{code:java}
109: iteration = matchingIterations[0];
{code}
we are assigning a value of matchingIterations\[0\] which is undefined.
Changing the line 108 seems to fix the issue. Here is a screenshot:
!solr-admin-replication-fixed.png!
was (Author: bvitnik):
OK. It was a quick find in the end. On line 107 we have:
{code:java}
107: var matchingIterations = find(iterations, failedDate);
{code}
Function "find" was returning an empty (zero length) array of iterations so
line 108 should be like this:
{code:java}
108: if (matchingIterations[0]) {
{code}
and not like this:
{code:java}
108: if (matchingIterations) {
{code}
if(matchingIterations) will always be true even when array is empty but on line
109:
{code:java}
iteration = matchingIterations[0];
{code}
we are assigning a value of matchingIterations\[0\] which is undefined.
Changing the line 108 seems to fix the issue. Here is a screenshot:
!solr-admin-replication-fixed.png!
> Admin Console error in solr 6.5
> ---
>
> Key: SOLR-10763
> URL: https://issues.apache.org/jira/browse/SOLR-10763
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 6.5.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: VIbhav Singh Rohilla
>Assignee: Jan Høydahl
> Fix For: master (7.0)
>
> Attachments: original UI.png, SOLR-10763.patch,
> solr-admin-replication-fixed.png, solr default console.png
>
>
> The default console of solr 6.5.1(on slave) is not able to show details of
> replication tab.
> But on clicking use "original UI" , the same tab is showing results.
> URL used - http://Solr_Slave_Host:8983/solr/cms/replication
> The inspect element error is -
> angular.js:11617 TypeError: Cannot set property 'status' of undefined
> at getIterations (replication.js:114)
> at replication.js:32
> at angular-resource.min.js:33
> at processQueue (angular.js:13193)
> at angular.js:13209
> at Scope.$eval (angular.js:14406)
> at Scope.$digest (angular.js:14222)
> at Scope.$apply (angular.js:14511)
> at done (angular.js:9669)
> at completeRequest (angular.js:9859)
> Please guide.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10763) Admin Console error in solr 6.5
[
https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060179#comment-16060179
]
Bojan Vitnik edited comment on SOLR-10763 at 6/22/17 11:18 PM:
---
OK. It was a quick find in the end. On line 107 we have:
{code:java}
107: var matchingIterations = find(iterations, failedDate);
{code}
Function "find" was returning an empty (zero length) array of iterations so
line 108 should be like this:
{code:java}
108: if (matchingIterations[0]) {
{code}
and not like this:
{code:java}
108: if (matchingIterations) {
{code}
if(matchingIterations) will always be true even when array is empty but on line
109:
{code:java}
iteration = matchingIterations[0];
{code}
we are assigning a value of matchingIterations\[0\] which is undefined.
Changing the line 108 seems to fix the issue. Here is a screenshot:
!solr-admin-replication-fixed.png!
was (Author: bvitnik):
OK. It was a quick find in the end. On line 107 we have:
{code:java}
107: var matchingIterations = find(iterations, failedDate);
{code}
Function "find" was returning an empty (zero length) array of iterations so
line 108 should be like this:
{code:java}
108: if (matchingIterations[0]) {
{code}
and not like this:
{code:java}
108: if (matchingIterations) {
{code}
if(matchingIterations) will always be true even when array is empty but on line
109:
{code:java}
iteration = matchingIterations[0];
{code}
we are assigning a value of matchingIterations\[0\] which is undefined.
Changing the line 108 seems to fix the issue. Here is a screenshot:
!solr-admin-replication-fixed.png|thumbnail!
> Admin Console error in solr 6.5
> ---
>
> Key: SOLR-10763
> URL: https://issues.apache.org/jira/browse/SOLR-10763
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 6.5.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: VIbhav Singh Rohilla
>Assignee: Jan Høydahl
> Fix For: master (7.0)
>
> Attachments: original UI.png, SOLR-10763.patch,
> solr-admin-replication-fixed.png, solr default console.png
>
>
> The default console of solr 6.5.1(on slave) is not able to show details of
> replication tab.
> But on clicking use "original UI" , the same tab is showing results.
> URL used - http://Solr_Slave_Host:8983/solr/cms/replication
> The inspect element error is -
> angular.js:11617 TypeError: Cannot set property 'status' of undefined
> at getIterations (replication.js:114)
> at replication.js:32
> at angular-resource.min.js:33
> at processQueue (angular.js:13193)
> at angular.js:13209
> at Scope.$eval (angular.js:14406)
> at Scope.$digest (angular.js:14222)
> at Scope.$apply (angular.js:14511)
> at done (angular.js:9669)
> at completeRequest (angular.js:9859)
> Please guide.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10763) Admin Console error in solr 6.5
[
https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060179#comment-16060179
]
Bojan Vitnik commented on SOLR-10763:
-
OK. It was a quick find in the end. On line 107 we have:
{code:java}
107: var matchingIterations = find(iterations, failedDate);
{code}
Function "find" was returning an empty (zero length) array of iterations so
line 108 should be like this:
{code:java}
108: if (matchingIterations[0]) {
{code}
and not like this:
{code:java}
108: if (matchingIterations) {
{code}
if(matchingIterations) will always be true even when array is empty but on line
109:
{code:java}
iteration = matchingIterations[0];
{code}
we are assigning a value of matchingIterations\[0\] which is undefined.
Changing the line 108 seems to fix the issue. Here is a screenshot:
!solr-admin-replication-fixed.png|thumbnail!
> Admin Console error in solr 6.5
> ---
>
> Key: SOLR-10763
> URL: https://issues.apache.org/jira/browse/SOLR-10763
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 6.5.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: VIbhav Singh Rohilla
>Assignee: Jan Høydahl
> Fix For: master (7.0)
>
> Attachments: original UI.png, SOLR-10763.patch,
> solr-admin-replication-fixed.png, solr default console.png
>
>
> The default console of solr 6.5.1(on slave) is not able to show details of
> replication tab.
> But on clicking use "original UI" , the same tab is showing results.
> URL used - http://Solr_Slave_Host:8983/solr/cms/replication
> The inspect element error is -
> angular.js:11617 TypeError: Cannot set property 'status' of undefined
> at getIterations (replication.js:114)
> at replication.js:32
> at angular-resource.min.js:33
> at processQueue (angular.js:13193)
> at angular.js:13209
> at Scope.$eval (angular.js:14406)
> at Scope.$digest (angular.js:14222)
> at Scope.$apply (angular.js:14511)
> at done (angular.js:9669)
> at completeRequest (angular.js:9859)
> Please guide.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bojan Vitnik updated SOLR-10763: Attachment: solr-admin-replication-fixed.png > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla >Assignee: Jan Høydahl > Fix For: master (7.0) > > Attachments: original UI.png, SOLR-10763.patch, > solr-admin-replication-fixed.png, solr default console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10939) JoinQParser gives incorrect results with numeric PointsFields
[
https://issues.apache.org/jira/browse/SOLR-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060162#comment-16060162
]
ASF subversion and git services commented on SOLR-10939:
Commit 8d92e08c9c19f478b944ac2d3d4735fc9bb921b0 in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8d92e08 ]
SOLR-10939: update @SuppressPointFields on TestJoin to note why points are
suppressed
Also update the annotation on TestCloudJSONFacetJoinDomain since SOLR-9989 is
resolved but the join problems
still prevent that test from passing with points enabled
> JoinQParser gives incorrect results with numeric PointsFields
> -
>
> Key: SOLR-10939
> URL: https://issues.apache.org/jira/browse/SOLR-10939
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> If you try to use the {{\{!join\}}} QParser with numeric points fields, you
> will get silently incorrect results.
> The underlying root cause seems to be that JoinQParser's JoinQuery assumes
> every field it's dealing with has indexed terms. (AFAICT it won't even work
> with {{indexed="false" docValues="true"}} Trie fields)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)
[ https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060163#comment-16060163 ] ASF subversion and git services commented on SOLR-9989: --- Commit 8d92e08c9c19f478b944ac2d3d4735fc9bb921b0 in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8d92e08 ] SOLR-10939: update @SuppressPointFields on TestJoin to note why points are suppressed Also update the annotation on TestCloudJSONFacetJoinDomain since SOLR-9989 is resolved but the join problems still prevent that test from passing with points enabled > Add support for PointFields in FacetModule (JSON Facets) > > > Key: SOLR-9989 > URL: https://issues.apache.org/jira/browse/SOLR-9989 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Tomás Fernández Löbbe >Assignee: Cao Manh Dat > Fix For: master (7.0) > > Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch > > > Followup task of SOLR-8396 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4096 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4096/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC 8 tests failed. FAILED: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test Error Message: Could not find collection:collection2 Stack Trace: java.lang.AssertionError: Could not find collection:collection2 at __randomizedtesting.SeedInfo.seed([48DB078C2CAE9CBD:C08F38568252F145]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:904) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612) at org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAda
[jira] [Commented] (SOLR-10763) Admin Console error in solr 6.5
[
https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060136#comment-16060136
]
Bojan Vitnik commented on SOLR-10763:
-
After applying the patch, I'm seeing another problem. Variable "iteration"
somehow ends up undefined in line 117:
{code:java}
117: iteration.latest = true;
{code}
Getting error "TypeError: Cannot set property 'latest' of undefined". I will
try to debug this tomorrow.
> Admin Console error in solr 6.5
> ---
>
> Key: SOLR-10763
> URL: https://issues.apache.org/jira/browse/SOLR-10763
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 6.5.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: VIbhav Singh Rohilla
>Assignee: Jan Høydahl
> Fix For: master (7.0)
>
> Attachments: original UI.png, SOLR-10763.patch, solr default
> console.png
>
>
> The default console of solr 6.5.1(on slave) is not able to show details of
> replication tab.
> But on clicking use "original UI" , the same tab is showing results.
> URL used - http://Solr_Slave_Host:8983/solr/cms/replication
> The inspect element error is -
> angular.js:11617 TypeError: Cannot set property 'status' of undefined
> at getIterations (replication.js:114)
> at replication.js:32
> at angular-resource.min.js:33
> at processQueue (angular.js:13193)
> at angular.js:13209
> at Scope.$eval (angular.js:14406)
> at Scope.$digest (angular.js:14222)
> at Scope.$apply (angular.js:14511)
> at done (angular.js:9669)
> at completeRequest (angular.js:9859)
> Please guide.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060121#comment-16060121 ] Jan Høydahl commented on SOLR-10763: I tried to reproduce the bug locally by failing some replications but without success. We need someone who see the issue to try this patch. > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla >Assignee: Jan Høydahl > Fix For: master (7.0) > > Attachments: original UI.png, SOLR-10763.patch, solr default > console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10939) JoinQParser gives incorrect results with numeric PointsFields
[
https://issues.apache.org/jira/browse/SOLR-10939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060122#comment-16060122
]
Hoss Man commented on SOLR-10939:
-
At the lucene level it appears that {{JoinUtil}} does support joining on
numeric Points fields (w/o DocValues) if the appropriate numeric type is
specified -- so it seems like:
* ScoreJoinQParser should use the numeric join if the from/to fields are numeric
* JoinQParser should behave as if {{score=None}} was specified (and delegate to
ScoreJoinQParser) if the from/to fields are numeric
* in both cases, better error handling should validate that the fields are of
the same numeric type.
> JoinQParser gives incorrect results with numeric PointsFields
> -
>
> Key: SOLR-10939
> URL: https://issues.apache.org/jira/browse/SOLR-10939
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> If you try to use the {{\{!join\}}} QParser with numeric points fields, you
> will get silently incorrect results.
> The underlying root cause seems to be that JoinQParser's JoinQuery assumes
> every field it's dealing with has indexed terms. (AFAICT it won't even work
> with {{indexed="false" docValues="true"}} Trie fields)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19939 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19939/ Java: 32bit/jdk1.8.0_131 -server -XX:+UseConcMarkSweepGC 5 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=12774, name=cdcr-update-log-synchronizer-5757-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748)2) Thread[id=12786, name=cdcr-update-log-synchronizer-5763-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=12774, name=cdcr-update-log-synchronizer-5757-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) 2) Thread[id=12786, name=cdcr-update-log-synchronizer-5763-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([590280CE9D101B03]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=12774, name=cdcr-update-log-synchronizer-5757-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecut
[jira] [Created] (SOLR-10939) JoinQParser gives incorrect results with numeric PointsFields
Hoss Man created SOLR-10939:
---
Summary: JoinQParser gives incorrect results with numeric
PointsFields
Key: SOLR-10939
URL: https://issues.apache.org/jira/browse/SOLR-10939
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
If you try to use the {{\{!join\}}} QParser with numeric points fields, you
will get silently incorrect results.
The underlying root cause seems to be that JoinQParser's JoinQuery assumes
every field it's dealing with has indexed terms. (AFAICT it won't even work
with {{indexed="false" docValues="true"}} Trie fields)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10915) Make SolrClient classes extendable without code duplication
[
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated SOLR-10915:
Attachment: SOLR-10915.patch
Thanks Jason. Patch looks good. I've fixed a typo here and there and removed
{{SolrExampleTests.java}} as it didn't really have any changes but just import
reordering.
Here's the updated patch.
I'm running the tests and I'll commit once the tests pass.
> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch, SOLR-10915.patch,
> SOLR-10915.patch.with-deprecations, SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has
> made it impossible to extend those classes without code duplication.
> As an example, if we wanted to extend HttpSolrClient we would also want to
> extend the Builder. The problem is that the constructor of the main class,
> does not accept the builder object but explicit parameters, and the inherited
> class doesn't have access to any of those values from the Builder object as
> they are all private.
> Generally, we'd want to have the client object constructor accept the
> Builder, instead of explicit values, and also make the Builder values
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that
> needs to be fixed before the major release, specially now that we know that
> this problem exists.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 1893 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1893/ 5 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=2287, name=testExecutor-1256-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=2287, name=testExecutor-1256-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:51188: Cannot unload non-existent core [multiunload0] at __randomizedtesting.SeedInfo.seed([CE6EC6E488D65656]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:222) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:372) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery Error Message: Path not found: /responseHeader/status Stack Trace: java.lang.RuntimeException: Path not found: /responseHeader/status at __randomizedtesting.SeedInfo.seed([C39776E1B24E6BDA:B69AB6FDA254AD0F]:0) at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329) at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271) at org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286) at org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184) at org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138) at org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassNam
[jira] [Commented] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas
[
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060048#comment-16060048
]
ASF subversion and git services commented on SOLR-10864:
Commit ae01113472378093462e88b90e6e07a2cd863f8f in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ae01113 ]
remove SuppressPointFields from TestCloudPivotFacet
now that SOLR-10864 is in place, there's no reason this test can't use
points+docValues
> Add static (test only) boolean to PointField indicating 'precisionStep'
> should be ignored so we can simplify points randomization in our schemas
>
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch,
> SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good
> randomized test coverage of Points fields, I'd like to add the following to
> the {{PointField}} class...
> {code}
> /**
> *
> * The Test framework can set this global variable to instruct PointField
> that
> * (on init) it should be tollerant of the precisionStep
> argument used by TrieFields.
> * This allows for simple randomization of TrieFields and PointFields w/o
> extensive duplication
> * of
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 791 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/791/ No tests ran. Build Log: [...truncated 25924 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (30.7 MB/sec) [smoker] check changes HTML... [smoker] download lucene-7.0.0-src.tgz... [smoker] 29.5 MB in 0.03 sec (893.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.tgz... [smoker] 69.0 MB in 0.08 sec (844.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.zip... [smoker] 79.3 MB in 0.09 sec (900.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-7.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6157 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6157 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 215 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.00 sec (214.9 MB/sec) [smoker] check changes HTML... [smoker] download solr-7.0.0-src.tgz... [smoker] 50.1 MB in 0.06 sec (776.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.0.0.tgz... [smoker] 141.3 MB in 0.18 sec (806.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-7.0.0.zip... [smoker] 142.3 MB in 0.17 sec (820.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-7.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-7.0.0.tgz... [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8 [smoker] Creating Solr home directory /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [smoker] Started Solr server on port 8983 (pid=21956). Happy searching! [smoker]
[jira] [Commented] (SOLR-8256) Set legacyCloud=false as default
[
https://issues.apache.org/jira/browse/SOLR-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059972#comment-16059972
]
Steve Rowe commented on SOLR-8256:
--
One more that reproduces with 8e9d685a402 checked out but not eff583ee8 :
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=ClusterStateUpdateTest -Dtests.method=testCoreRegistration
-Dtests.seed=B2BE41F52973DA2D -Dtests.slow=true -Dtests.locale=ar-OM
-Dtests.timezone=America/Argentina/Jujuy -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 3.56s J9 | ClusterStateUpdateTest.testCoreRegistration <<<
[junit4]> Throwable #1: org.junit.ComparisonFailure:
expected: but
was:
[junit4]>at
__randomizedtesting.SeedInfo.seed([B2BE41F52973DA2D:C35275A5009D418]:0)
[junit4]>at
org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration(ClusterStateUpdateTest.java:104)
{noformat}
> Set legacyCloud=false as default
>
>
> Key: SOLR-8256
> URL: https://issues.apache.org/jira/browse/SOLR-8256
> Project: Solr
> Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch,
> SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch
>
>
> We don't have the old back compat concerns anymore. It's time to remove this
> mostly unknown setting and start defaulting to this behavior that starts us
> down the path of zk=truth.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_131) - Build # 6670 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6670/ Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseParallelGC 8 tests failed. FAILED: org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi Error Message: Error from server at http://127.0.0.1:64399/solr: java.nio.file.InvalidPathException: Illegal char <�> at index 53: C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr�uildsolr-core estJ1 empsolr.handler.V2ApiIntegrationTest_242D1B564226F38C-001 empDir-002 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: Error from server at http://127.0.0.1:64399/solr: java.nio.file.InvalidPathException: Illegal char <�> at index 53: C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr�uildsolr-core estJ1 empsolr.handler.V2ApiIntegrationTest_242D1B564226F38C-001 empDir-002 at __randomizedtesting.SeedInfo.seed([242D1B564226F38C:F8B3FCD7FA3F9732]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:787) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:583) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:222) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:460) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:390) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1135) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:876) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi(V2ApiIntegrationTest.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at co
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+173) - Build # 19938 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19938/ Java: 32bit/jdk-9-ea+173 -client -XX:+UseSerialGC 6 tests failed. FAILED: org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats Error Message: Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1 Stack Trace: java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1 at __randomizedtesting.SeedInfo.seed([492DA1F53BCE5E90:86B3C4CCB43F36CF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:143) at org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:77) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Mes
[jira] [Resolved] (SOLR-10921) Make boolean query clause limit configurable per-query
[ https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-10921. - Resolution: Fixed Assignee: Yonik Seeley > Make boolean query clause limit configurable per-query > -- > > Key: SOLR-10921 > URL: https://issues.apache.org/jira/browse/SOLR-10921 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0) > > Attachments: SOLR-10921.patch, SOLR-10921.patch > > > This is the Solr version of LUCENE-7880 > Background: The removal of the arbitrary maxBooleanClauses has been blocked > in SOLR-4586, and there were objections to adding the ability to override > maxBooleanClauses at the Lucene level in LUCENE-7880. > That leaves us with this last option of implementing the check in solr by > raising the lucene limit and then using the maxBooleanClauses from > solrconfig.xml to throw an exception when the limit is exceeded. Solr > QParsers have access to the request object, which knows the > schema/core/config. This should fix the last-core-wins behavior due to the > lucene limit being a static. > Although this enables controlling the limit on a per-query basis, this issue > is not about adding any user API to do so. The capability will only be used > to make the current Solr maxBooleanClauses setting truly per-solr-core rather > than last-core-wins. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10921) Make boolean query clause limit configurable per-query
[ https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059919#comment-16059919 ] ASF subversion and git services commented on SOLR-10921: Commit 98276481e4104d4916a6b0e901d79c6b81f68d30 in lucene-solr's branch refs/heads/master from [~yo...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9827648 ] SOLR-10921: raise lucene BooleanQuery.maxClauseCount, add higher level checking via QueryUtils.build > Make boolean query clause limit configurable per-query > -- > > Key: SOLR-10921 > URL: https://issues.apache.org/jira/browse/SOLR-10921 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Yonik Seeley > Fix For: master (7.0) > > Attachments: SOLR-10921.patch, SOLR-10921.patch > > > This is the Solr version of LUCENE-7880 > Background: The removal of the arbitrary maxBooleanClauses has been blocked > in SOLR-4586, and there were objections to adding the ability to override > maxBooleanClauses at the Lucene level in LUCENE-7880. > That leaves us with this last option of implementing the check in solr by > raising the lucene limit and then using the maxBooleanClauses from > solrconfig.xml to throw an exception when the limit is exceeded. Solr > QParsers have access to the request object, which knows the > schema/core/config. This should fix the last-core-wins behavior due to the > lucene limit being a static. > Although this enables controlling the limit on a per-query basis, this issue > is not about adding any user API to do so. The capability will only be used > to make the current Solr maxBooleanClauses setting truly per-solr-core rather > than last-core-wins. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7737) Remove spatial-extras dependency on queries
[ https://issues.apache.org/jira/browse/LUCENE-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059868#comment-16059868 ] David Smiley commented on LUCENE-7737: -- Also ShapePredicate's javadocs are no longer correct as it's no longer a ValueSource. This class used to be named ShapePredicateValueSource. May I suggest renaming to ShapeValuesPredicate? It does _have_ a ShapeValueSource so it seems appropriate to reflect that in some way. > Remove spatial-extras dependency on queries > --- > > Key: LUCENE-7737 > URL: https://issues.apache.org/jira/browse/LUCENE-7737 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Alan Woodward >Priority: Minor > Fix For: master (7.0) > > Attachments: LUCENE-7737.patch, LUCENE-7737.patch > > > The spatial-extras module uses ValueSources for a number of different > purposes, requiring a dependency on the queries module. I'd like to try > using core-only interfaces here instead, allowing us to remove the dependency -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10496) Implement ComputePlanAction for autoscaling
[ https://issues.apache.org/jira/browse/SOLR-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059855#comment-16059855 ] ASF subversion and git services commented on SOLR-10496: Commit b023b011934be9ea411e148538daaa0a0b1d2052 in lucene-solr's branch refs/heads/jira/SOLR-10496 from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b023b01 ] SOLR-10496: Fix test failure on nodeLost event > Implement ComputePlanAction for autoscaling > --- > > Key: SOLR-10496 > URL: https://issues.apache.org/jira/browse/SOLR-10496 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: autoscaling > Fix For: master (7.0) > > Attachments: SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch > > > The ComputePlanAction will use the cluster/collection policy to calculate the > cluster operations to be performed. This issue is about integrating the work > done in SOLR-10278 with the trigger framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7883) Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
[
https://issues.apache.org/jira/browse/LUCENE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-7883.
---
Resolution: Fixed
I added changes and migrate entries and committed to master (7.0).
> Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
> -
>
> Key: LUCENE-7883
> URL: https://issues.apache.org/jira/browse/LUCENE-7883
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7883.patch
>
>
> As discussed in LUCENE-7873, the use of
> {{Thread.currentThread().getContextClassLoader()}} is in most cases a bug
> caused by sloppy usage of ClassLoader APIs and should be replaced by
> {{getClass().getClassLoader()}}.
> In Lucene we only have the ClassPathResourceLoader, but this one can be
> solved by removing the "default" constructor. It only affects CustomAnalyzer,
> that should also be extended in Lucene 7.
> The uses in Solr and its test are all to be replaced by
> {{getClass().getClassLoader()}} (except some workaround with clustering using
> a try-finally). This is in most cases historical code, when Solr was a web
> application to workaround some buggy webapp containers. In the current state,
> the code is "just wrong".
> Finally, we should add {{java.lang.Thread#getContextClassLoader()}} to
> forbidden-apis.
> I'd like to get this into Lucene 7, as it affects some APIs in Lucene.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7883) Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
[
https://issues.apache.org/jira/browse/LUCENE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059812#comment-16059812
]
ASF subversion and git services commented on LUCENE-7883:
-
Commit 5de15ff403fbf4afe68718151617e6104f7e3888 in lucene-solr's branch
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5de15ff ]
LUCENE-7883: Lucene/Solr no longer uses the context class loader when resolving
resources
> Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
> -
>
> Key: LUCENE-7883
> URL: https://issues.apache.org/jira/browse/LUCENE-7883
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7883.patch
>
>
> As discussed in LUCENE-7873, the use of
> {{Thread.currentThread().getContextClassLoader()}} is in most cases a bug
> caused by sloppy usage of ClassLoader APIs and should be replaced by
> {{getClass().getClassLoader()}}.
> In Lucene we only have the ClassPathResourceLoader, but this one can be
> solved by removing the "default" constructor. It only affects CustomAnalyzer,
> that should also be extended in Lucene 7.
> The uses in Solr and its test are all to be replaced by
> {{getClass().getClassLoader()}} (except some workaround with clustering using
> a try-finally). This is in most cases historical code, when Solr was a web
> application to workaround some buggy webapp containers. In the current state,
> the code is "just wrong".
> Finally, we should add {{java.lang.Thread#getContextClassLoader()}} to
> forbidden-apis.
> I'd like to get this into Lucene 7, as it affects some APIs in Lucene.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10937) No space left on device when building suggester index
[
https://issues.apache.org/jira/browse/SOLR-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059775#comment-16059775
]
Matthew Caruana Galizia edited comment on SOLR-10937 at 6/22/17 6:04 PM:
-
Thank you. That was indeed the issue. Setting
{{SOLR_OPTS="$SOLR_OPTS -Djava.io.tmpdir=/path/to/other/tmp"}}
in solr.in.sh did the trick. Mentioning the path would definitely help. I'm too
busy to work on a patch this week and the next, but perhaps after that.
was (Author: mcaruanagalizia):
Thank you. That was indeed the issue. Setting
{{SOLR_OPTS="$SOLR_OPTS -Djava.io.tmpdir=/path/to/other/tmp"}}
in solr.in.sh did the trick. Mentioning the path would definitely help. I'm too
busy to work on a path this week and the next, but perhaps after that.
> No space left on device when building suggester index
> -
>
> Key: SOLR-10937
> URL: https://issues.apache.org/jira/browse/SOLR-10937
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.6
> Environment: Ubuntu 16
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
> Labels: filesystem, suggester
>
> On startup, I see the following error in my logs even though the disk has
> 600GB of free space available (and 3GB on the root filesystem):
> {code:java}
> 2017-06-22 08:53:01.862 ERROR (searcherExecutor-8-thread-1-processing-x:kc) [
> x:kc] o.a.s.h.c.SuggestComponent Exception in building suggester index for:
> suggester
> java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
> at java.nio.channels.Channels.writeFully(Channels.java:101)
> at java.nio.channels.Channels.access$000(Channels.java:61)
> at java.nio.channels.Channels$1.write(Channels.java:174)
> at
> org.apache.lucene.store.FSDirectory$FSIndexOutput$1.write(FSDirectory.java:419)
> at java.util.zip.CheckedOutputStream.write(CheckedOutputStream.java:73)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
> at
> org.apache.lucene.store.OutputStreamIndexOutput.writeBytes(OutputStreamIndexOutput.java:53)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:524)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:499)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:612)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:588)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.lucene.util.SameThreadExecutorService.execute(SameThreadExecutorService.java:34)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
> at org.apache.lucene.util.OfflineSorter.sort(OfflineSorter.java:285)
> at
> org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:489)
> at org.apache.lucene.search.suggest.Lookup.build(Lookup.java:190)
> at
> org.apache.solr.spelling.suggest.SolrSuggester.build(SolrSuggester.java:181)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.buildSuggesterIndex(SuggestComponent.java:524)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.newSearcher(SuggestComponent.java:506)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at
> sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
[jira] [Commented] (SOLR-10937) No space left on device when building suggester index
[
https://issues.apache.org/jira/browse/SOLR-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059775#comment-16059775
]
Matthew Caruana Galizia commented on SOLR-10937:
Thank you. That was indeed the issue. Setting
{{SOLR_OPTS="$SOLR_OPTS -Djava.io.tmpdir=/path/to/other/tmp"}}
in solr.in.sh did the trick. Mentioning the path would definitely help. I'm too
busy to work on a path this week and the next, but perhaps after that.
> No space left on device when building suggester index
> -
>
> Key: SOLR-10937
> URL: https://issues.apache.org/jira/browse/SOLR-10937
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.6
> Environment: Ubuntu 16
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
> Labels: filesystem, suggester
>
> On startup, I see the following error in my logs even though the disk has
> 600GB of free space available (and 3GB on the root filesystem):
> {code:java}
> 2017-06-22 08:53:01.862 ERROR (searcherExecutor-8-thread-1-processing-x:kc) [
> x:kc] o.a.s.h.c.SuggestComponent Exception in building suggester index for:
> suggester
> java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
> at java.nio.channels.Channels.writeFully(Channels.java:101)
> at java.nio.channels.Channels.access$000(Channels.java:61)
> at java.nio.channels.Channels$1.write(Channels.java:174)
> at
> org.apache.lucene.store.FSDirectory$FSIndexOutput$1.write(FSDirectory.java:419)
> at java.util.zip.CheckedOutputStream.write(CheckedOutputStream.java:73)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
> at
> org.apache.lucene.store.OutputStreamIndexOutput.writeBytes(OutputStreamIndexOutput.java:53)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:524)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:499)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:612)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:588)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.lucene.util.SameThreadExecutorService.execute(SameThreadExecutorService.java:34)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
> at org.apache.lucene.util.OfflineSorter.sort(OfflineSorter.java:285)
> at
> org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:489)
> at org.apache.lucene.search.suggest.Lookup.build(Lookup.java:190)
> at
> org.apache.solr.spelling.suggest.SolrSuggester.build(SolrSuggester.java:181)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.buildSuggesterIndex(SuggestComponent.java:524)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.newSearcher(SuggestComponent.java:506)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at
> sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
> at java.nio.channels.Channels.writeFull
[JENKINS] Lucene-Solr-Tests-master - Build # 1892 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1892/ 8 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=10621, name=testExecutor-4286-thread-2, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=10621, name=testExecutor-4286-thread-2, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:34383: Cannot unload non-existent core [multiunload1] at __randomizedtesting.SeedInfo.seed([D4B268B77E0726CE]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:222) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:372) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.update.HardAutoCommitTest.testCommitWithin Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([D4B268B77E0726CE:6E6007CFFD29C8DB]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:872) at org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.
[jira] [Comment Edited] (SOLR-10307) Provide SSL/TLS keystore password a more secure way
[
https://issues.apache.org/jira/browse/SOLR-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055445#comment-16055445
]
Michael Suzuki edited comment on SOLR-10307 at 6/22/17 5:52 PM:
Yes the above example works for me, it is worth updating the documentation on
how to setup ssl as above.
I was setting all the details in solr.ini.sh as per the documentation. To
recreate my issue start a new terminal and insure none of the values are set,
verify by using echo.
{code}
echo $SOLR_SSL_ENABLED
echo $SOLR_SSL_KEY_STORE
echo $SOLR_SSL_KEY_STORE_PASSWORD
echo $SOLR_SSL_TRUST_STORE
echo $SOLR_SSL_TRUST_STORE_PASSWORD
{code}
Then uncomment and set the values in solr.ini.sh and start solr, expected to
work instead an error is thrown "Keystore was tampered with, or password was
incorrect".
was (Author: michaelsuzuki):
Yes the above example works for me, it is worth updating the documentation on
how to setup ssl as above.
I was setting all the details in solr.ini.sh as per the documentation. To
recreate my issue start a new terminal and insure none of the values are set,
verify by using echo.
{code}
echo $SOLR_SSL_ENABLED
echo $SOLR_SSL_KEY_STORE
echo $SOLR_SSL_KEY_STORE_PASSWORD
echo $SOLR_SSL_TRUST_STORE
echo $SOLR_SSL_TRUST_STORE_PASSWORD
{code}
Then uncomment and set the values in solr.ini.sh and start solr, expected to
work instead and error is thrown "Keystore was tampered with, or password was
incorrect".
> Provide SSL/TLS keystore password a more secure way
> ---
>
> Key: SOLR-10307
> URL: https://issues.apache.org/jira/browse/SOLR-10307
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10307.2.patch, SOLR-10307.patch, SOLR-10307.patch,
> SOLR-10307.patch
>
>
> Currently the only way to pass server and client side SSL keytstore and
> truststore passwords is to set specific environment variables that will be
> passed as system properties, through command line parameter.
> First option is to pass passwords through environment variables which gives a
> better level of protection. Second option would be to use hadoop credential
> provider interface to access credential store.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7737) Remove spatial-extras dependency on queries
[
https://issues.apache.org/jira/browse/LUCENE-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059746#comment-16059746
]
David Smiley commented on LUCENE-7737:
--
* in LatLonPointSpatialField did you purposefully remove
{{@SuppressWarnings("unchecked")}} for the cast? If so why? If not please put
back.
* perhaps move GeoDistValueSourceParser.WrappedDoubleValueSource to
ValueSource.toDoubleValueSource (inverse of .asDoubleValueSource) ?
* SerializedDVStrategy.ShapeDocValueSource: You can now simply remove the
BytesRefBuilder here. I recall I once had this to avoid re-fetching the
docValues.binaryValue() when callers sometimes call exists() but that's no
longer pertinent with the move to an iteration based API.
* Maybe define ShapeValues as inner class of ShapeValueSource?
* Why the changes to geo3d test stuff?
* Why the change to DistanceStrategyTest?
Thanks again for all your work on this issue!
> Remove spatial-extras dependency on queries
> ---
>
> Key: LUCENE-7737
> URL: https://issues.apache.org/jira/browse/LUCENE-7737
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Reporter: Alan Woodward
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: LUCENE-7737.patch, LUCENE-7737.patch
>
>
> The spatial-extras module uses ValueSources for a number of different
> purposes, requiring a dependency on the queries module. I'd like to try
> using core-only interfaces here instead, allowing us to remove the dependency
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19937 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19937/ Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 6 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=8134, name=testExecutor-3990-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=8134, name=testExecutor-3990-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:34755: Cannot unload non-existent core [multiunload0] at __randomizedtesting.SeedInfo.seed([419C89536DD2DFBB]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:222) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:372) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=11418, name=cdcr-update-log-synchronizer-5924-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748)2) Thread[id=11406, name=cdcr-update-log-synchronizer-5918-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=11418, name=cdcr-update-log-synchronizer-5924-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) 2) Thread[id=11406, name=cdcr-update-log-synchronizer-5918-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicat
[jira] [Commented] (SOLR-10307) Provide SSL/TLS keystore password a more secure way
[ https://issues.apache.org/jira/browse/SOLR-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059721#comment-16059721 ] Mano Kovacs commented on SOLR-10307: [~markrmil...@gmail.com], could you please take a look at the fix patch? The issue what [~michaelsuzuki] pointed out probably will affect others. > Provide SSL/TLS keystore password a more secure way > --- > > Key: SOLR-10307 > URL: https://issues.apache.org/jira/browse/SOLR-10307 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Mano Kovacs >Assignee: Mark Miller > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10307.2.patch, SOLR-10307.patch, SOLR-10307.patch, > SOLR-10307.patch > > > Currently the only way to pass server and client side SSL keytstore and > truststore passwords is to set specific environment variables that will be > passed as system properties, through command line parameter. > First option is to pass passwords through environment variables which gives a > better level of protection. Second option would be to use hadoop credential > provider interface to access credential store. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10938) SuppressPointFields should require a bugUrl
Hoss Man created SOLR-10938: --- Summary: SuppressPointFields should require a bugUrl Key: SOLR-10938 URL: https://issues.apache.org/jira/browse/SOLR-10938 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Hoss Man the SuppressPointFields annotation currently leaves bugUrl as an optional attribute -- we should make it required to ensure no one disables points on a test w/o having a a known open jira tracking the underlying problem -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10807) Randomize PointFields in all tests unless explicit reason not to
[ https://issues.apache.org/jira/browse/SOLR-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059696#comment-16059696 ] Hoss Man commented on SOLR-10807: - FWIW: now that SOLR-10864 has landed on master, I'm probably going to abandon the jira/SOLR-10807 branch (which has served it's purpose for experimentation) and move forward with multiple individual sub-tasks focusing on adding the (new) randomized variables into more and more schema files/tests in small chunks untill we have them everywhere. > Randomize PointFields in all tests unless explicit reason not to > - > > Key: SOLR-10807 > URL: https://issues.apache.org/jira/browse/SOLR-10807 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: > core.test.log.fde06f34b7f9d0916a134b3efaa8780892ff8e39.txt, core.test.log.txt > > > We need to seriously beef up our testing of PointFields to figure out what > Solr features don't currently work with PointFields. > The existing Trie/Point randomization logic in SolrTestCaseJ4 is a good start > -- but only a handful of schema files leverage it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
How to enable NER Plugin in Solr 6.x
I need to enable NER Plugin in Solr 6.x in order to extract locations from the text when committing documents to Solr . How can I achieve this in the simpliest way possible? Please help Christian Fotache Tel: 0728.297.207
[jira] [Commented] (SOLR-10937) No space left on device when building suggester index
[
https://issues.apache.org/jira/browse/SOLR-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059688#comment-16059688
]
Varun Thacker commented on SOLR-10937:
--
Hi Matthew,
The AnalyzingSuggester uses a tmp dir to build the FST (
https://lucene.apache.org/core/6_6_0/suggest/org/apache/lucene/search/suggest/analyzing/AnalyzingSuggester.html
) and then deletes the tmp dir once it's built.
So this has nothing to do with your disk space on your normal drive but with
the tmp dir that the JVM is using.
The suggester doesn't let you specify the tmp in the solrconfig file , but the
dir path read by this System Property ( -Djava.io.tmpdir ) which defaults Java
defaults to /tmp on linux I believe
Maybe we could do two things here to help the user:
- Mention the path which run out of disk space
- Document that the AnalyzingSuggester/FuzzySuggester requires a tmp dir to
build the suggester.
We could leave this Jira open to address those. Would you be interested in
submitting a patch?
> No space left on device when building suggester index
> -
>
> Key: SOLR-10937
> URL: https://issues.apache.org/jira/browse/SOLR-10937
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.6
> Environment: Ubuntu 16
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
> Labels: filesystem, suggester
>
> On startup, I see the following error in my logs even though the disk has
> 600GB of free space available (and 3GB on the root filesystem):
> {code:java}
> 2017-06-22 08:53:01.862 ERROR (searcherExecutor-8-thread-1-processing-x:kc) [
> x:kc] o.a.s.h.c.SuggestComponent Exception in building suggester index for:
> suggester
> java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
> at java.nio.channels.Channels.writeFully(Channels.java:101)
> at java.nio.channels.Channels.access$000(Channels.java:61)
> at java.nio.channels.Channels$1.write(Channels.java:174)
> at
> org.apache.lucene.store.FSDirectory$FSIndexOutput$1.write(FSDirectory.java:419)
> at java.util.zip.CheckedOutputStream.write(CheckedOutputStream.java:73)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
> at
> org.apache.lucene.store.OutputStreamIndexOutput.writeBytes(OutputStreamIndexOutput.java:53)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:524)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:499)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:612)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:588)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.lucene.util.SameThreadExecutorService.execute(SameThreadExecutorService.java:34)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
> at org.apache.lucene.util.OfflineSorter.sort(OfflineSorter.java:285)
> at
> org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:489)
> at org.apache.lucene.search.suggest.Lookup.build(Lookup.java:190)
> at
> org.apache.solr.spelling.suggest.SolrSuggester.build(SolrSuggester.java:181)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.buildSuggesterIndex(SuggestComponent.java:524)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.newSearcher(SuggestComponent.java:506)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Supp
[jira] [Commented] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[
https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059682#comment-16059682
]
Hoss Man commented on SOLR-10503:
-
bq. I made them static inner classes, but as a result had to add exceptional
classloader logic to load CurrencyFieldType inner classes (currently only
FileExchangeRateProvider).
Oh ... uck ... i'm sorry, i hadn't even thought about that -- I was just trying
to avoid "polluting" the schema package with what felt like implementation
details, I didn't even think about the fact that those classes can be
configured by name... Please ignore that suggestion and go back to the simpler
code you had before unless you think this is better for some reason.
bq. I've made this change. I think the user experience would be better with
defaults for the majority of folks who I'm guessing won't care about sub-field
details. But I'm ok with not providing them.
My take is that I'd rather we provide those "defaults" in our _sample_
configsets where they are more obvious to users who want to tweak them, and we
can trivially change them overtime w/o breaking backcompat for users who
upgrade w/their existing configs -- having "defaults in code" are much harder
for us to change.
Other notes...
* why do we need {{MethodHandles.lookup()}} in {{CurrencyFieldType.init}} and
{{checkSchemaField}} -- wouldn't {{this.getClass()}} work just as well?
* {{CurrencyField.inform(IndexSchema)}} should be calling {{super.inform()}} as
it's last step (and as a result doesn't need to explicitly assign
{{this.schema}}
> CurrencyField should be changed from TrieLongField to LongPointField for
> underlying raw-polyfield
> -
>
> Key: SOLR-10503
> URL: https://issues.apache.org/jira/browse/SOLR-10503
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-10503.patch, SOLR-10503.patch, SOLR-10503.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10921) Make boolean query clause limit configurable per-query
[
https://issues.apache.org/jira/browse/SOLR-10921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-10921:
Attachment: SOLR-10921.patch
Updated patch that added a test and changed the style to this:
{code}
- return q.build();
+ return QueryUtils.build(q, parser);
{code}
> Make boolean query clause limit configurable per-query
> --
>
> Key: SOLR-10921
> URL: https://issues.apache.org/jira/browse/SOLR-10921
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Yonik Seeley
> Fix For: master (7.0)
>
> Attachments: SOLR-10921.patch, SOLR-10921.patch
>
>
> This is the Solr version of LUCENE-7880
> Background: The removal of the arbitrary maxBooleanClauses has been blocked
> in SOLR-4586, and there were objections to adding the ability to override
> maxBooleanClauses at the Lucene level in LUCENE-7880.
> That leaves us with this last option of implementing the check in solr by
> raising the lucene limit and then using the maxBooleanClauses from
> solrconfig.xml to throw an exception when the limit is exceeded. Solr
> QParsers have access to the request object, which knows the
> schema/core/config. This should fix the last-core-wins behavior due to the
> lucene limit being a static.
> Although this enables controlling the limit on a per-query basis, this issue
> is not about adding any user API to do so. The capability will only be used
> to make the current Solr maxBooleanClauses setting truly per-solr-core rather
> than last-core-wins.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas
[
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-10864.
-
Resolution: Fixed
> Add static (test only) boolean to PointField indicating 'precisionStep'
> should be ignored so we can simplify points randomization in our schemas
>
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch,
> SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good
> randomized test coverage of Points fields, I'd like to add the following to
> the {{PointField}} class...
> {code}
> /**
> *
> * The Test framework can set this global variable to instruct PointField
> that
> * (on init) it should be tollerant of the precisionStep
> argument used by TrieFields.
> * This allows for simple randomization of TrieFields and PointFields w/o
> extensive duplication
> * of
[jira] [Commented] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas
[
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059645#comment-16059645
]
ASF subversion and git services commented on SOLR-10864:
Commit 38f29b2674c2465057d522e5862b8a32b1637a71 in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=38f29b2 ]
SOLR-10864: Simplified how Trie vs Points based numerics are randomized by
SolrTestCaseJ4
Adds a static option to PointsField to ignore 'precisionStep' attribute.
This change also begins to attempt to randomize 'docValues' on numeric field
types unless tests explicity enable/disable them
> Add static (test only) boolean to PointField indicating 'precisionStep'
> should be ignored so we can simplify points randomization in our schemas
>
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch,
> SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good
> randomized test coverage of Points fields, I'd like to add the following to
> the {{PointField}} class...
> {code}
> /**
> *
> * The Test framework can set this global variable to instruct PointField
> that
> * (on init) it should be tollerant of the precisionStep
> argument used by TrieFields.
> * This allows for simple randomization of TrieFields and PointFields w/o
> extensive duplication
> * of
[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit
[
https://issues.apache.org/jira/browse/SOLR-10568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059576#comment-16059576
]
Steve Rowe commented on SOLR-10568:
---
bq. I think we can disable the 6_6 builds now, Steve Rowe.
Done.
bq. Also, I wonder if we could increase the frequency of the builds to at least
every hour for all jobs on each branch?
I set frequency to {{@hourly}} on {{Solr-reference-guide-6.6}},
{{Solr-reference-guide-6.x}}, and {{Solr-reference-guide-master}}.
> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to
> verify the presentation of the information is as expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7623) Add FunctionScoreQuery and FunctionMatchQuery
[ https://issues.apache.org/jira/browse/LUCENE-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059551#comment-16059551 ] David Smiley commented on LUCENE-7623: -- I'm a little surprised to see these additions in the Lucene queries module because I thought there was an overarching intent to bring the functionality of ValueSource's into Lucene core. Ramification: Now in LUCENE-7737 I think I see a case where spatial-extras PointVectorStrategy is adding a bunch more code that could be avoided if FunctionMatchQuery were in core. Note that the Solr legacy copy of PointVectorStrategy in LUCENE-7737 is able to simply use FunctionMatchQuery. > Add FunctionScoreQuery and FunctionMatchQuery > - > > Key: LUCENE-7623 > URL: https://issues.apache.org/jira/browse/LUCENE-7623 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Fix For: 6.5 > > Attachments: LUCENE-7623.patch, LUCENE-7623.patch, LUCENE-7623.patch, > LUCENE-7623.patch, LUCENE-7623.patch, LUCENE-7623.patch > > > We should update the various function scoring queries to use the new > DoubleValues API -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19936 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19936/ Java: 32bit/jdk1.8.0_131 -server -XX:+UseParallelGC 6 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=2140, name=testExecutor-861-thread-8, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=2140, name=testExecutor-861-thread-8, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:43199: Cannot create 1 new replicas for collection multiunload given the current number of live nodes and a maxShardsPerNode of 1 at __randomizedtesting.SeedInfo.seed([B4CAF3F0346FBD9A]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:222) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195) at org.apache.solr.cloud.BasicDistributedZkTest.lambda$createCores$0(BasicDistributedZkTest.java:595) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration Error Message: expected: but was: Stack Trace: org.junit.ComparisonFailure: expected: but was: at __randomizedtesting.SeedInfo.seed([B4CAF3F0346FBD9A:A41955F4D15B3AF]:0) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration(ClusterStateUpdateTest.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apach
[jira] [Commented] (LUCENE-7737) Remove spatial-extras dependency on queries
[ https://issues.apache.org/jira/browse/LUCENE-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059519#comment-16059519 ] David Smiley commented on LUCENE-7737: -- I see DoubleValueSource.explain was changed from being abstract to having a default implementation. Does that really belong in this issue? (as an aside, reviewing extensive patch files like this is error-prone and a pain; it'd be nice to use other mechanisms) > Remove spatial-extras dependency on queries > --- > > Key: LUCENE-7737 > URL: https://issues.apache.org/jira/browse/LUCENE-7737 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Alan Woodward >Priority: Minor > Fix For: master (7.0) > > Attachments: LUCENE-7737.patch, LUCENE-7737.patch > > > The spatial-extras module uses ValueSources for a number of different > purposes, requiring a dependency on the queries module. I'd like to try > using core-only interfaces here instead, allowing us to remove the dependency -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10496) Implement ComputePlanAction for autoscaling
[ https://issues.apache.org/jira/browse/SOLR-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059506#comment-16059506 ] ASF subversion and git services commented on SOLR-10496: Commit b78e7ff589510315463488cd1ed79244d9d6e6ad in lucene-solr's branch refs/heads/jira/SOLR-10496 from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b78e7ff ] SOLR-10496: MOVEREPLICA suggester for dead node is not working > Implement ComputePlanAction for autoscaling > --- > > Key: SOLR-10496 > URL: https://issues.apache.org/jira/browse/SOLR-10496 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: autoscaling > Fix For: master (7.0) > > Attachments: SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch > > > The ComputePlanAction will use the cluster/collection policy to calculate the > cluster operations to be performed. This issue is about integrating the work > done in SOLR-10278 with the trigger framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10935) BALANCESHARDUNIQUE does not distribute properties correctly
[ https://issues.apache.org/jira/browse/SOLR-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059503#comment-16059503 ] Erick Erickson commented on SOLR-10935: --- First: BALANCESHARDUNIQUE will probably be going away so it's unlikely this will be addressed. Second: the small added burden of a particular node being leader is not a problem unless you start having 100s of leaders on the same node. Small discrepancies aren't much concern. the use-case this was built for was having several hundred shards each with a replica on each machine (very special circumstances). So when that the cluster was coming up, _all_ the leaders would be on the same node. Unless you're in that situation it's a waste of time worrying about it. Third: If you really _must_ get them perfectly balanced, you can use ADDREPLICAPROP to move the offending property arounc. > BALANCESHARDUNIQUE does not distribute properties correctly > --- > > Key: SOLR-10935 > URL: https://issues.apache.org/jira/browse/SOLR-10935 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 6.2 >Reporter: Daisy.Yuan > > Create a collection of 8 slices on 4 nodes, 2 replicas of each slice. > Node IP is: > 192.168.182.246:21101 > 192.168.182.247:21104 > 192.168.182.248:21101 > 192.168.182.149:21104 > After executing the BALANCESHARDUNIQUE command, the leader node is balanced > as follows: > Shard1 192.168.182.248:21101 > Shard2 192.168.182.249:21104 > Shard3 192.168.182.246:21101 > Shard4 192.168.182.249:21104 > Shard5 192.168.182.246:21101 > Shard6 192.168.182.248:21101 > Shard7 192.168.182.249:21104 > Shard8 192.168.182.247:21104 > The correct expected result should be that there are two leader on each node. > But the actual result is.. > there are 3 leaders on 192.168.182.249:21104, > and only one Leader on 192.168.182.247:21104 > the others are distributed correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10937) No space left on device when building suggester index
[
https://issues.apache.org/jira/browse/SOLR-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059502#comment-16059502
]
Matthew Caruana Galizia edited comment on SOLR-10937 at 6/22/17 3:01 PM:
-
Thank you for that suggestion. Before I post, perhaps you could let me know
what you think based on the following:
- the size of the index is 375 GB
- there are 10,824,670 documents
- there's 612 GB free on the Solr data partition
- the index is fully optimised (segment count is 1)
The error happens every time the core is loaded. For example, when Solr is
restarted or I press the Reload button in the Core Admin section on the Solr UI.
was (Author: mcaruanagalizia):
Thank you for that suggestion. Before I post, perhaps you could let me know
what you think based on the following:
- the size of the index is 375 GB
- there are 10,824,670 documents
- there's 612 GB free on the Solr data partition
- the index is fully optimised (segment count is 1)
The error happens every time the core is loaded. For example, when Solr is
restarted or I press the Reload button the Core Admin section on the Solr UI.
> No space left on device when building suggester index
> -
>
> Key: SOLR-10937
> URL: https://issues.apache.org/jira/browse/SOLR-10937
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.6
> Environment: Ubuntu 16
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
> Labels: filesystem, suggester
>
> On startup, I see the following error in my logs even though the disk has
> 600GB of free space available (and 3GB on the root filesystem):
> {code:java}
> 2017-06-22 08:53:01.862 ERROR (searcherExecutor-8-thread-1-processing-x:kc) [
> x:kc] o.a.s.h.c.SuggestComponent Exception in building suggester index for:
> suggester
> java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
> at java.nio.channels.Channels.writeFully(Channels.java:101)
> at java.nio.channels.Channels.access$000(Channels.java:61)
> at java.nio.channels.Channels$1.write(Channels.java:174)
> at
> org.apache.lucene.store.FSDirectory$FSIndexOutput$1.write(FSDirectory.java:419)
> at java.util.zip.CheckedOutputStream.write(CheckedOutputStream.java:73)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
> at
> org.apache.lucene.store.OutputStreamIndexOutput.writeBytes(OutputStreamIndexOutput.java:53)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:524)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:499)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:612)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:588)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.lucene.util.SameThreadExecutorService.execute(SameThreadExecutorService.java:34)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
> at org.apache.lucene.util.OfflineSorter.sort(OfflineSorter.java:285)
> at
> org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:489)
> at org.apache.lucene.search.suggest.Lookup.build(Lookup.java:190)
> at
> org.apache.solr.spelling.suggest.SolrSuggester.build(SolrSuggester.java:181)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.buildSuggesterIndex(SuggestComponent.java:524)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.newSearcher(SuggestComponent.java:506)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> a
[jira] [Commented] (SOLR-10937) No space left on device when building suggester index
[
https://issues.apache.org/jira/browse/SOLR-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059502#comment-16059502
]
Matthew Caruana Galizia commented on SOLR-10937:
Thank you for that suggestion. Before I post, perhaps you could let me know
what you think based on the following:
- the size of the index is 375 GB
- there are 10,824,670 documents
- there's 612 GB free on the Solr data partition
- the index is fully optimised (segment count is 1)
The error happens every time the core is loaded. For example, when Solr is
restarted or I press the Reload button the Core Admin section on the Solr UI.
> No space left on device when building suggester index
> -
>
> Key: SOLR-10937
> URL: https://issues.apache.org/jira/browse/SOLR-10937
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.6
> Environment: Ubuntu 16
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
> Labels: filesystem, suggester
>
> On startup, I see the following error in my logs even though the disk has
> 600GB of free space available (and 3GB on the root filesystem):
> {code:java}
> 2017-06-22 08:53:01.862 ERROR (searcherExecutor-8-thread-1-processing-x:kc) [
> x:kc] o.a.s.h.c.SuggestComponent Exception in building suggester index for:
> suggester
> java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
> at java.nio.channels.Channels.writeFully(Channels.java:101)
> at java.nio.channels.Channels.access$000(Channels.java:61)
> at java.nio.channels.Channels$1.write(Channels.java:174)
> at
> org.apache.lucene.store.FSDirectory$FSIndexOutput$1.write(FSDirectory.java:419)
> at java.util.zip.CheckedOutputStream.write(CheckedOutputStream.java:73)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
> at
> org.apache.lucene.store.OutputStreamIndexOutput.writeBytes(OutputStreamIndexOutput.java:53)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:524)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:499)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:612)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:588)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.lucene.util.SameThreadExecutorService.execute(SameThreadExecutorService.java:34)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
> at org.apache.lucene.util.OfflineSorter.sort(OfflineSorter.java:285)
> at
> org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:489)
> at org.apache.lucene.search.suggest.Lookup.build(Lookup.java:190)
> at
> org.apache.solr.spelling.suggest.SolrSuggester.build(SolrSuggester.java:181)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.buildSuggesterIndex(SuggestComponent.java:524)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.newSearcher(SuggestComponent.java:506)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at
> sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileC
[jira] [Commented] (SOLR-10937) No space left on device when building suggester index
[
https://issues.apache.org/jira/browse/SOLR-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059496#comment-16059496
]
Erick Erickson commented on SOLR-10937:
---
Please raise this question on the user's list at solr-u...@lucene.apache.org,
see: (http://lucene.apache.org/solr/community.html#mailing-lists-irc) there are
a _lot_ more people watching that list who may be able to help.
If it's determined that this is a code issue in Solr and not a
configuration/usage problem, we can raise a JIRA.
Segment merging can cause your _entire_ index to be copied, so you always need
at least as much free space on your disk as your indexes occupy. When you post
this on the user's list, please include how much total disk space your indexes
that use that disk occupy. And whether this happens all the time or was a
one-time problem.
> No space left on device when building suggester index
> -
>
> Key: SOLR-10937
> URL: https://issues.apache.org/jira/browse/SOLR-10937
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Suggester
>Affects Versions: 6.6
> Environment: Ubuntu 16
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
> Labels: filesystem, suggester
>
> On startup, I see the following error in my logs even though the disk has
> 600GB of free space available (and 3GB on the root filesystem):
> {code:java}
> 2017-06-22 08:53:01.862 ERROR (searcherExecutor-8-thread-1-processing-x:kc) [
> x:kc] o.a.s.h.c.SuggestComponent Exception in building suggester index for:
> suggester
> java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> at java.nio.channels.Channels.writeFullyImpl(Channels.java:78)
> at java.nio.channels.Channels.writeFully(Channels.java:101)
> at java.nio.channels.Channels.access$000(Channels.java:61)
> at java.nio.channels.Channels$1.write(Channels.java:174)
> at
> org.apache.lucene.store.FSDirectory$FSIndexOutput$1.write(FSDirectory.java:419)
> at java.util.zip.CheckedOutputStream.write(CheckedOutputStream.java:73)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
> at
> org.apache.lucene.store.OutputStreamIndexOutput.writeBytes(OutputStreamIndexOutput.java:53)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:524)
> at
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:499)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:612)
> at
> org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:588)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.lucene.util.SameThreadExecutorService.execute(SameThreadExecutorService.java:34)
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
> at org.apache.lucene.util.OfflineSorter.sort(OfflineSorter.java:285)
> at
> org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:489)
> at org.apache.lucene.search.suggest.Lookup.build(Lookup.java:190)
> at
> org.apache.solr.spelling.suggest.SolrSuggester.build(SolrSuggester.java:181)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.buildSuggesterIndex(SuggestComponent.java:524)
> at
> org.apache.solr.handler.component.SuggestComponent$SuggesterListener.newSearcher(SuggestComponent.java:506)
> at
> org.apache.solr.core.SolrCore.lambda$getSearcher$15(SolrCore.java:2249)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.io.IOException: No space left on device
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at
> sun.nio.ch.FileD
[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit
[ https://issues.apache.org/jira/browse/SOLR-10568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059466#comment-16059466 ] Cassandra Targett commented on SOLR-10568: -- I think we can disable the 6_6 builds now, [~steve_rowe]. Also, I wonder if we could increase the frequency of the builds to at least every hour for all jobs on each branch? It only takes a few minutes to build so it could be more frequent, particularly on master and any branch we're hoping to release somewhat soon. I think after that we can resolve this and just communicate needs for builds the way we do for the full Lucene/Solr packages (via the list). > Automate HTML builds via Jenkins to occur with each commit > -- > > Key: SOLR-10568 > URL: https://issues.apache.org/jira/browse/SOLR-10568 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Priority: Minor > > Spin-off from SOLR-10295. > The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so > Jenkins builds of HTML format of the Ref Guide occur as soon as commits are > made to any non-released branch. > This would allow any committer to see doc changes ASAP after a commit to > verify the presentation of the information is as expected. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 378 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/378/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor220.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088) at org.apache.solr.core.SolrCore.(SolrCore.java:947) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:930) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor220.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1088) at org.apache.solr.core.SolrCore.(SolrCore.java:947) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:930) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:565) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([3940C40812A9F8EE]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:302) at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-9183) Test ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing is failing
[
https://issues.apache.org/jira/browse/SOLR-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059419#comment-16059419
]
Alan Woodward commented on SOLR-9183:
-
This has started failing for me too, Mac OS Sierra, Java 1.8.0_74.
> Test ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing
> is failing
>
>
> Key: SOLR-9183
> URL: https://issues.apache.org/jira/browse/SOLR-9183
> Project: Solr
> Issue Type: Bug
>Reporter: Keith Laban
>
> This is causing tests to fail for me on 6x and master
> The test introduced in SOLR-8522
> {{ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing}}
> is failing for me.
> {code}
> java.lang.AssertionError:
> Expected: is <0>
> got: <1>
> at org.junit.Assert.assertThat(Assert.java:780)
> at org.junit.Assert.assertThat(Assert.java:738)
> at
> org.apache.solr.cloud.rule.ImplicitSnitchTest.testGetTags_with_wrong_ipv4_format_ip_returns_nothing(ImplicitSnitchTest.java:101)
> 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:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> {code}
> I suspect that
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/rule/ImplicitSnitch.java#L130
> should be returning null causing the failures.
> I'll run the test at home to see if it has something to do with the corporate
> network I'm running on.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10496) Implement ComputePlanAction for autoscaling
[ https://issues.apache.org/jira/browse/SOLR-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059403#comment-16059403 ] Shalin Shekhar Mangar commented on SOLR-10496: -- Strange, these commits shouldn't show up in Jira because of the exclusion we have in place for all branches starting with jira. > Implement ComputePlanAction for autoscaling > --- > > Key: SOLR-10496 > URL: https://issues.apache.org/jira/browse/SOLR-10496 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: autoscaling > Fix For: master (7.0) > > Attachments: SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch > > > The ComputePlanAction will use the cluster/collection policy to calculate the > cluster operations to be performed. This issue is about integrating the work > done in SOLR-10278 with the trigger framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-10763: -- Assignee: Jan Høydahl > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla >Assignee: Jan Høydahl > Fix For: master (7.0) > > Attachments: original UI.png, SOLR-10763.patch, solr default > console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10496) Implement ComputePlanAction for autoscaling
[ https://issues.apache.org/jira/browse/SOLR-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059376#comment-16059376 ] ASF subversion and git services commented on SOLR-10496: Commit cb665a1b35cbd1826c58f8d4ff8f20eb37bc5f8f in lucene-solr's branch refs/heads/jira/SOLR-10496 from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cb665a1 ] SOLR-10496: Fix ClassCastException because the SRC_NODE hint is a Set > Implement ComputePlanAction for autoscaling > --- > > Key: SOLR-10496 > URL: https://issues.apache.org/jira/browse/SOLR-10496 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: autoscaling > Fix For: master (7.0) > > Attachments: SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch > > > The ComputePlanAction will use the cluster/collection policy to calculate the > cluster operations to be performed. This issue is about integrating the work > done in SOLR-10278 with the trigger framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-10763: --- Attachment: SOLR-10763.patch Thanks [~bvitnik] for the research. Attaching patch. Not tested. [~vibhav.rohi...@timesinternet.in] can you try? The patch is for master, but I believe it will apply to latest few 6.x too? Or you can try to modify the same things. The code path that apparently is wrong is when there are failed replications in the list. So to reproduce one would need to have a master/slave setup, then run a few replications, and then perhaps shut down master to have a few failed replications. > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla > Fix For: master (7.0) > > Attachments: original UI.png, SOLR-10763.patch, solr default > console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10496) Implement ComputePlanAction for autoscaling
[ https://issues.apache.org/jira/browse/SOLR-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059322#comment-16059322 ] ASF subversion and git services commented on SOLR-10496: Commit ebf298329360240014253daf58ab4699f3685033 in lucene-solr's branch refs/heads/jira/SOLR-10496 from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ebf2983 ] SOLR-10496: Initial patch for ComputePlanAction > Implement ComputePlanAction for autoscaling > --- > > Key: SOLR-10496 > URL: https://issues.apache.org/jira/browse/SOLR-10496 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: autoscaling > Fix For: master (7.0) > > Attachments: SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, SOLR-10496.patch, > SOLR-10496.patch > > > The ComputePlanAction will use the cluster/collection policy to calculate the > cluster operations to be performed. This issue is about integrating the work > done in SOLR-10278 with the trigger framework. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+173) - Build # 19935 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19935/ Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=532, name=cdcr-update-log-synchronizer-187-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@9-ea/java.lang.Thread.run(Thread.java:844)2) Thread[id=544, name=cdcr-update-log-synchronizer-193-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@9-ea/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=532, name=cdcr-update-log-synchronizer-187-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@9-ea/java.lang.Thread.run(Thread.java:844) 2) Thread[id=544, name=cdcr-update-log-synchronizer-193-thread-1, state=WAITING, group=TGRP-CdcrVersionReplicationTest] at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119) at java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@9-ea/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([F0779E0AD277E742]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersi
[jira] [Commented] (SOLR-10763) Admin Console error in solr 6.5
[
https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16059312#comment-16059312
]
Bojan Vitnik commented on SOLR-10763:
-
Here is an example of my replication configuration in "solrconfig.xml":
{code:java}
startup
commit
optimize
optimize
solrconfig.xml,...
00:00:10
${enable.slave:false}
http://${solr.master}:8983/solr/collection1
00:00:60
10
200
{code}
variable "enable.slave" is defined in "core.properties" like:
{code:java}
enable.slave=true
{code}
I'm well aware that this is probably an unsupported configuration (host acting
as master and slave at the same time) and wrong configuration in many ways. I
found this configuration while debugging replication problems for one of our
clients.
On the other hands, code in line 111 of "replication.js" is very much wrong too.
> Admin Console error in solr 6.5
> ---
>
> Key: SOLR-10763
> URL: https://issues.apache.org/jira/browse/SOLR-10763
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 6.5.1
> Environment: CentOS Linux release 7.2.1511 (Core)
>Reporter: VIbhav Singh Rohilla
> Fix For: master (7.0)
>
> Attachments: original UI.png, solr default console.png
>
>
> The default console of solr 6.5.1(on slave) is not able to show details of
> replication tab.
> But on clicking use "original UI" , the same tab is showing results.
> URL used - http://Solr_Slave_Host:8983/solr/cms/replication
> The inspect element error is -
> angular.js:11617 TypeError: Cannot set property 'status' of undefined
> at getIterations (replication.js:114)
> at replication.js:32
> at angular-resource.min.js:33
> at processQueue (angular.js:13193)
> at angular.js:13209
> at Scope.$eval (angular.js:14406)
> at Scope.$digest (angular.js:14222)
> at Scope.$apply (angular.js:14511)
> at done (angular.js:9669)
> at completeRequest (angular.js:9859)
> Please guide.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-10763) Admin Console error in solr 6.5
[ https://issues.apache.org/jira/browse/SOLR-10763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reopened SOLR-10763: Reopening to try to reproduce > Admin Console error in solr 6.5 > --- > > Key: SOLR-10763 > URL: https://issues.apache.org/jira/browse/SOLR-10763 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.5.1 > Environment: CentOS Linux release 7.2.1511 (Core) >Reporter: VIbhav Singh Rohilla > Fix For: master (7.0) > > Attachments: original UI.png, solr default console.png > > > The default console of solr 6.5.1(on slave) is not able to show details of > replication tab. > But on clicking use "original UI" , the same tab is showing results. > URL used - http://Solr_Slave_Host:8983/solr/cms/replication > The inspect element error is - > angular.js:11617 TypeError: Cannot set property 'status' of undefined > at getIterations (replication.js:114) > at replication.js:32 > at angular-resource.min.js:33 > at processQueue (angular.js:13193) > at angular.js:13209 > at Scope.$eval (angular.js:14406) > at Scope.$digest (angular.js:14222) > at Scope.$apply (angular.js:14511) > at done (angular.js:9669) > at completeRequest (angular.js:9859) > Please guide. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
