[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ https://issues.apache.org/jira/browse/SOLR-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15624565#comment-15624565 ] Shalin Shekhar Mangar commented on SOLR-9481: - bq. I got no idea how the changes entry made it to 6.x though, sorry for that Shalin Shekhar Mangar. I should apologize because I made a wrong merge commit which added this issue in CHANGES.txt on branch_6x. However, I just noticed that this issue is still in the 6.3 section on master. Please move it to 6.4 when you can. > BasicAuthPlugin should support standalone mode > -- > > Key: SOLR-9481 > URL: https://issues.apache.org/jira/browse/SOLR-9481 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: authentication > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9481.patch, SOLR-9481.patch > > > The BasicAuthPlugin currently only supports SolrCloud, and reads users and > credentials from ZK /security.json > Add support for standalone mode operation -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7532) Add Lucene 6.2 file format description in codecs/lucene62/package-info.java
[ https://issues.apache.org/jira/browse/LUCENE-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shinichiro Abe updated LUCENE-7532: --- Attachment: LUCENE-7532.patch Here is a patch for branch_6x. I carried over the content from branch_6_1 and updated segment info links and history as 62 codec. > Add Lucene 6.2 file format description in codecs/lucene62/package-info.java > --- > > Key: LUCENE-7532 > URL: https://issues.apache.org/jira/browse/LUCENE-7532 > Project: Lucene - Core > Issue Type: Bug > Components: core/codecs >Affects Versions: 6.2 >Reporter: Shinichiro Abe > Attachments: LUCENE-7532.patch > > > Currently that description is missing at branch_6x so I'd like to restore it. > User feedback: http://markmail.org/message/hxtxzue7qn6ne6vz -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7532) Add Lucene 6.2 file format description in codecs/lucene62/package-info.java
Shinichiro Abe created LUCENE-7532: -- Summary: Add Lucene 6.2 file format description in codecs/lucene62/package-info.java Key: LUCENE-7532 URL: https://issues.apache.org/jira/browse/LUCENE-7532 Project: Lucene - Core Issue Type: Bug Components: core/codecs Affects Versions: 6.2 Reporter: Shinichiro Abe Currently that description is missing at branch_6x so I'd like to restore it. User feedback: http://markmail.org/message/hxtxzue7qn6ne6vz -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 6.3.0
I have created release notes for Lucene and Solr. Please edit to improve as you see fit. Lucene: https://wiki.apache.org/lucene-java/ReleaseNote63 Solr: https://wiki.apache.org/solr/ReleaseNote63 On Wed, Oct 26, 2016 at 2:16 PM, Shalin Shekhar Mangar wrote: > It looks like 6.3.0 has accumulated enough new features, optimizations and > fixes. How do folks feel about pushing this release out? > > I volunteer to be the RM. If there are no objections, I'd like to put the > first RC to vote on Monday. > > -- > Regards, > Shalin Shekhar Mangar. -- Regards, Shalin Shekhar Mangar. - 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_102) - Build # 6218 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6218/ Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.security.BasicAuthStandaloneTest.testBasicAuth Error Message: Invalid jsonError 401 HTTP ERROR: 401 Problem accessing /solr/admin/authentication. Reason: Bad credentials http://eclipse.org/jetty";>Powered by Jetty:// 9.3.8.v20160314 Stack Trace: java.lang.AssertionError: Invalid json Error 401 HTTP ERROR: 401 Problem accessing /solr/admin/authentication. Reason: Bad credentials http://eclipse.org/jetty";>Powered by Jetty:// 9.3.8.v20160314 at __randomizedtesting.SeedInfo.seed([89F7DD5B01C6CD5E:3599AB49A5954E24]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.security.BasicAuthIntegrationTest.verifySecurityStatus(BasicAuthIntegrationTest.java:256) at org.apache.solr.security.BasicAuthIntegrationTest.verifySecurityStatus(BasicAuthIntegrationTest.java:237) at org.apache.solr.security.BasicAuthStandaloneTest.testBasicAuth(BasicAuthStandaloneTest.java:106) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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.ru
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 485 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/485/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 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 at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102) at sun.reflect.GeneratedConstructorAccessor176.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:706) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:768) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1007) at org.apache.solr.core.SolrCore.(SolrCore.java:872) at org.apache.solr.core.SolrCore.(SolrCore.java:776) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:842) at org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:202) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:102) at sun.reflect.GeneratedConstructorAccessor176.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:706) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:768) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1007) at org.apache.solr.core.SolrCore.(SolrCore.java:872) at org.apache.solr.core.SolrCore.(SolrCore.java:776) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:842) at org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([650B26C6F5B6140E]: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:260) at sun.reflect.GeneratedMethodAccessor20.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 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.State
[jira] [Updated] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-9681: --- Attachment: SOLR-9681.patch Patch attached > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch, SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7531) Remove packing support from FST
[ https://issues.apache.org/jira/browse/LUCENE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15624116#comment-15624116 ] David Smiley commented on LUCENE-7531: -- I like the reduction in complexity. What's the motivation? Does the packing feature just seem not worth it? > Remove packing support from FST > --- > > Key: LUCENE-7531 > URL: https://issues.apache.org/jira/browse/LUCENE-7531 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-7531.patch > > > This seems to be only used for the kuromoji dictionaries, but we could easily > rebuild those dictionaries with packing disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+140) - Build # 2086 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2086/ Java: 32bit/jdk-9-ea+140 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.component.SpellCheckComponentTest.testThresholdTokenFrequency Error Message: Path not found: /spellcheck/suggestions/[1]/suggestion Stack Trace: java.lang.RuntimeException: Path not found: /spellcheck/suggestions/[1]/suggestion at __randomizedtesting.SeedInfo.seed([DD694F7520D829B0:57CEC084AF3310CB]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:900) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:847) at org.apache.solr.handler.component.SpellCheckComponentTest.testThresholdTokenFrequency(SpellCheckComponentTest.java:277) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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:367) at java.lang.Thread.run(java.base@9-ea/Thread.java:843) Build Log: [...truncated 11776 lines...] [jun
[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 508 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/508/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit Error Message: expected:<1> but was:<2> Stack Trace: java.lang.AssertionError: expected:<1> but was:<2> at __randomizedtesting.SeedInfo.seed([8392609E3AE01633:7ADFF33106955BB9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:280) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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)
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18188 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18188/ Java: 64bit/jdk-9-ea+140 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([FDC1D793C68F9BD4:AB239CB00673432]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1329) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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:367) at java.lang.Thread.run(java.ba
[jira] [Commented] (LUCENE-7531) Remove packing support from FST
[ https://issues.apache.org/jira/browse/LUCENE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623675#comment-15623675 ] Michael McCandless commented on LUCENE-7531: +1 > Remove packing support from FST > --- > > Key: LUCENE-7531 > URL: https://issues.apache.org/jira/browse/LUCENE-7531 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-7531.patch > > > This seems to be only used for the kuromoji dictionaries, but we could easily > rebuild those dictionaries with packing disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - 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 # 190 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/190/ 4 tests failed. FAILED: org.apache.lucene.index.TestIndexWriterWithThreads.testImmediateDiskFullWithThreads Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([A2675433BE91738A]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterWithThreads Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([A2675433BE91738A]:0) FAILED: org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.testCollectionsAPI Error Message: Expected to see collection awhollynewcollection_0 null Last available state: DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/2)={ "replicationFactor":"3", "shards":{"shard1":{ "range":"8000-7fff", "state":"active", "replicas":{}}}, "router":{"name":"compositeId"}, "maxShardsPerNode":"1", "autoAddReplicas":"false"} Stack Trace: java.lang.AssertionError: Expected to see collection awhollynewcollection_0 null Last available state: DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/2)={ "replicationFactor":"3", "shards":{"shard1":{ "range":"8000-7fff", "state":"active", "replicas":{}}}, "router":{"name":"compositeId"}, "maxShardsPerNode":"1", "autoAddReplicas":"false"} at __randomizedtesting.SeedInfo.seed([8DBDC023EAAA0C40:C5C8B497EC9923D5]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:236) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:496) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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(
[jira] [Updated] (SOLR-9708) Expose UnifiedHighlighter in Solr
[ https://issues.apache.org/jira/browse/SOLR-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-9708: --- Assignee: David Smiley Priority: Major (was: Minor) Fix Version/s: 6.4 Issue Type: New Feature (was: Improvement) > Expose UnifiedHighlighter in Solr > - > > Key: SOLR-9708 > URL: https://issues.apache.org/jira/browse/SOLR-9708 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: highlighter >Reporter: Timothy M. Rodriguez >Assignee: David Smiley > Fix For: 6.4 > > > This ticket is for creating a Solr plugin that can utilize the new > UnifiedHighlighter which was initially committed in > https://issues.apache.org/jira/browse/LUCENE-7438 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9708) Expose UnifiedHighlighter in Solr
[ https://issues.apache.org/jira/browse/SOLR-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623477#comment-15623477 ] David Smiley commented on SOLR-9708: To anyone following along: The code is the PostingsHighlighter's Solr adapter, with just a few changes to work with the UH instead. > Expose UnifiedHighlighter in Solr > - > > Key: SOLR-9708 > URL: https://issues.apache.org/jira/browse/SOLR-9708 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: highlighter >Reporter: Timothy M. Rodriguez >Priority: Minor > > This ticket is for creating a Solr plugin that can utilize the new > UnifiedHighlighter which was initially committed in > https://issues.apache.org/jira/browse/LUCENE-7438 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result
[ https://issues.apache.org/jira/browse/SOLR-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623472#comment-15623472 ] Joel Bernstein commented on SOLR-9616: -- [~timo.schmidt], in looking through the stack track trace and reviewing the code, it appears that the index you were searching on was empty. Was that the case? > Solr throws exception when expand=true on empty result > -- > > Key: SOLR-9616 > URL: https://issues.apache.org/jira/browse/SOLR-9616 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.2.1 >Reporter: Timo Hund >Priority: Critical > Fix For: 6.2.1 > > > When i run a query with expand=true with field collapsing and the result set > is empty an exception is thrown: > solr:8984/solr/core_en/select?&fq={!collapse > field=pid}&expand=true&expand.rows=10 > Produces: > "error":{ > "msg":"Index: 0, Size: 0", > "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat > java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat > java.util.ArrayList.get(ArrayList.java:429)\n\tat > java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat > org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat > org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat > > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat > > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat > > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat > > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat > > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat > java.lang.Thread.run(Thread.java:745)\n", > "code":500}} > Instead i would assume to get an empty result. > Is this a bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9665) Facet Values Sort Order: Add 3rd choice: Numeric Sort
[ https://issues.apache.org/jira/browse/SOLR-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623462#comment-15623462 ] David Smiley commented on SOLR-9665: If the field is numeric (not a String that happens to contain a number), then the "JSON Facet API" will interpret the "index" sort order as the numeric sort of the field value. I just verified it worked: http://localhost:8983/solr/techproducts/select?json.facet.price.terms.field=price&json.facet.price.terms.sort=index&indent=on&q=*:*&rows=1&wt=json (in that example, it's a coincidence of the example data that it's the same as count order) Docs: https://cwiki.apache.org/confluence/display/solr/Faceted+Search p.s. yes it's a shame we have multiple faceting modules, which is confusing to users. In time I hope JSON Facet API takes over. > Facet Values Sort Order: Add 3rd choice: Numeric Sort > - > > Key: SOLR-9665 > URL: https://issues.apache.org/jira/browse/SOLR-9665 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: faceting >Reporter: Luke P Warwick > > As a person, I need facet values to be in predictable, intuitive spots so > that I can quickly and easily find the values that are appropriate to me. > Problem Statement: Today Solr has two default facet sort orders, neither of > which provides predictable, intuitive facet value orders for people when the > values start with numbers. > Goal: Address the problem where index sorts facet values how a computer would > rather than how a human would. This is very problematic for E-commerce > facets like 'size' and 'tire width' > Acceptance Criteria: > 1. Sorts facet values numerically from lowest to highest > 2. Works with both numeric and string fields (thus working on values that > include letters... 25 mm, 30 waist, 32 Waist, 4 Petite) > 3. If facet values don't start with a number, they are sorted alphabetically, > after all values that do start with a number > 4. If facet values are equal numerically, sort the numerically equal values > alphabetically. Example: 10,10 Petite,10 Tall,12, Petite, 12 Tall > 5. Integers and Floats are supported (even if string field) > Examples: > Women's Pants Sizes: > 8 > 8 Tall > 10 > 10 Petite > 10 Tall > 12 > 12 Tall > 14 Petite > 26 Waist > 28 Waist > 30 Waist > One Size > Bike Wheel Sizes: > 20 Inches > 24 Inches > 26 Inches > 27 Inches > 27.5 Inches > 27.5+ Inches > 29 Inches > 650c > 700c -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7438) UnifiedHighlighter
[ https://issues.apache.org/jira/browse/LUCENE-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623451#comment-15623451 ] Timothy M. Rodriguez commented on LUCENE-7438: -- Not yet, we have an initial general implementation, but it's lacking tests. (We have a customized extension internally that does have tests.) I've created a new ticket https://issues.apache.org/jira/browse/SOLR-9708 with a PR containing the initial impl so folks can follow or help the work towards finishing it up. Thanks for asking though, hopefully this gets the ball rolling faster. > UnifiedHighlighter > -- > > Key: LUCENE-7438 > URL: https://issues.apache.org/jira/browse/LUCENE-7438 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Affects Versions: 6.2 >Reporter: Timothy M. Rodriguez >Assignee: David Smiley > Fix For: 6.3 > > Attachments: LUCENE-7438.patch, LUCENE_7438_UH_benchmark.patch, > LUCENE_7438_UH_benchmark.patch, LUCENE_7438_UH_small_changes.patch > > > The UnifiedHighlighter is an evolution of the PostingsHighlighter that is > able to highlight using offsets in either postings, term vectors, or from > analysis (a TokenStream). Lucene’s existing highlighters are mostly > demarcated along offset source lines, whereas here it is unified -- hence > this proposed name. In this highlighter, the offset source strategy is > separated from the core highlighting functionalty. The UnifiedHighlighter > further improves on the PostingsHighlighter’s design by supporting accurate > phrase highlighting using an approach similar to the standard highlighter’s > WeightedSpanTermExtractor. The next major improvement is a hybrid offset > source strategythat utilizes postings and “light” term vectors (i.e. just the > terms) for highlighting multi-term queries (wildcards) without resorting to > analysis. Phrase highlighting and wildcard highlighting can both be disabled > if you’d rather highlight a little faster albeit not as accurately reflecting > the query. > We’ve benchmarked an earlier version of this highlighter comparing it to the > other highlighters and the results were exciting! It’s tempting to share > those results but it’s definitely due for another benchmark, so we’ll work on > that. Performance was the main motivator for creating the UnifiedHighlighter, > as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy > requirements) wasn’t fast enough, even with term vectors along with several > improvements we contributed back, and even after we forked it to highlight in > multiple threads. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9708) Expose UnifiedHighlighter in Solr
[ https://issues.apache.org/jira/browse/SOLR-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623438#comment-15623438 ] ASF GitHub Bot commented on SOLR-9708: -- GitHub user Timothy055 opened a pull request: https://github.com/apache/lucene-solr/pull/107 SOLR-9708 UnifiedHighlighter Solr Plugin An initial implementation of a solr plugin for the unified highlighter. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Timothy055/lucene-solr features/SOLR-9708 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/107.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #107 commit 669f94f27c73b9fd5190a980a089cff9d4df3015 Author: Timothy Rodriguez Date: 2016-10-31T21:05:47Z initial commit of UnifiedSolrHighlighter adapter commit 2cf4b2d35f1f535e8b8126b5dd685dc3bb663391 Author: Timothy Rodriguez Date: 2016-10-31T21:12:19Z add license header > Expose UnifiedHighlighter in Solr > - > > Key: SOLR-9708 > URL: https://issues.apache.org/jira/browse/SOLR-9708 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: highlighter >Reporter: Timothy M. Rodriguez >Priority: Minor > > This ticket is for creating a Solr plugin that can utilize the new > UnifiedHighlighter which was initially committed in > https://issues.apache.org/jira/browse/LUCENE-7438 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #107: SOLR-9708 UnifiedHighlighter Solr Plugin
GitHub user Timothy055 opened a pull request: https://github.com/apache/lucene-solr/pull/107 SOLR-9708 UnifiedHighlighter Solr Plugin An initial implementation of a solr plugin for the unified highlighter. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Timothy055/lucene-solr features/SOLR-9708 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/107.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #107 commit 669f94f27c73b9fd5190a980a089cff9d4df3015 Author: Timothy Rodriguez Date: 2016-10-31T21:05:47Z initial commit of UnifiedSolrHighlighter adapter commit 2cf4b2d35f1f535e8b8126b5dd685dc3bb663391 Author: Timothy Rodriguez Date: 2016-10-31T21:12:19Z add license header --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9623) Disable remote streaming by default
[ https://issues.apache.org/jira/browse/SOLR-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623435#comment-15623435 ] Jan Høydahl edited comment on SOLR-9623 at 10/31/16 9:12 PM: - You mean to build EnvVar override support into the Java code for each config property instead of relying on solr.xml to have the config? Would be sweet if we had some kind of dot convention that would always work, like {{solr...}}, e.g. {{solr.config.request_parsers.enable_remote_streaming}}, here with a convention of inserting a "_" for camelCase. Makes me think - we already have such a mepping convention for the Config REST API, don't we? was (Author: janhoy): You mean to build EnvVar override support into the Java code for each config property instead of relying on solr.xml to have the config? Would be sweet if we had some kind of dot convention that would always work, like {{solr...}}, e.g. {{solr.config.request_parsers.enable_remote_streaming}}, here with a convention of inserting a "_" for camelCase. > Disable remote streaming by default > --- > > Key: SOLR-9623 > URL: https://issues.apache.org/jira/browse/SOLR-9623 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl > Labels: configset > > As we set more and more config settings suitable for production use, perhaps > it is time to disable remoteStreaming by default, and document how to enable > it. > In all config sets, change into > {code:xml} > multipartUploadLimitInKB="2048000" >formdataUploadLimitInKB="2048" >addHttpRequestToContext="false"/> > {code} > And then consider adding support for it in solr.in.xxx -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9623) Disable remote streaming by default
[ https://issues.apache.org/jira/browse/SOLR-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623435#comment-15623435 ] Jan Høydahl commented on SOLR-9623: --- You mean to build EnvVar override support into the Java code for each config property instead of relying on solr.xml to have the config? Would be sweet if we had some kind of dot convention that would always work, like {{solr...}}, e.g. {{solr.config.request_parsers.enable_remote_streaming}}, here with a convention of inserting a "_" for camelCase. > Disable remote streaming by default > --- > > Key: SOLR-9623 > URL: https://issues.apache.org/jira/browse/SOLR-9623 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl > Labels: configset > > As we set more and more config settings suitable for production use, perhaps > it is time to disable remoteStreaming by default, and document how to enable > it. > In all config sets, change into > {code:xml} > multipartUploadLimitInKB="2048000" >formdataUploadLimitInKB="2048" >addHttpRequestToContext="false"/> > {code} > And then consider adding support for it in solr.in.xxx -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9708) Expose UnifiedHighlighter in Solr
Timothy M. Rodriguez created SOLR-9708: -- Summary: Expose UnifiedHighlighter in Solr Key: SOLR-9708 URL: https://issues.apache.org/jira/browse/SOLR-9708 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: highlighter Reporter: Timothy M. Rodriguez Priority: Minor This ticket is for creating a Solr plugin that can utilize the new UnifiedHighlighter which was initially committed in https://issues.apache.org/jira/browse/LUCENE-7438 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[ https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623410#comment-15623410 ] Jan Høydahl edited comment on SOLR-9609 at 10/31/16 9:00 PM: - My reasoning is that it is not likely something you ever need to change, so using solr.in for overriding looks better than needing to upload stuff to ZK config. And the risk of having different solr.in files is not unique to this setting. We already need SOLR_ZK_HOST to be synchronized as well as probably SSL settings. I think this is in the same neighborhood of deciding the basic wiring of how hosts will talk to eachother. That's why I also think urlScheme could move from being a clusterProp to becoming a sysProp in solr.in, or being auto-resolved from SSL props. And SOLR-9481 is *only* in master so far btw... was (Author: janhoy): My reasoning is that it is not likely something you ever need to change, so using solr.in for overriding looks better than needing to upload stuff to ZK config. And the risk of having different solr.in files is not unique to this setting. We already need SOLR_ZK_HOST to be synchronized as well as probably SSL settings. I think this is in the same neighborhood of deciding the basic wiring of how hosts will talk to eachother. That's why I also think urlScheme could move from being a clusterProp to becoming a sysProp in solr.in, or being auto-resolved from SSL props. > Change hard-coded keysize from 512 to 1024 > -- > > Key: SOLR-9609 > URL: https://issues.apache.org/jira/browse/SOLR-9609 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jeremy Martini >Assignee: Erick Erickson > Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log > > > In order to configure our dataSource without requiring a plaintext password > in the configuration file, we extended JdbcDataSource to create our own > custom implementation. Our dataSource config now looks something like this: > {code:xml} > url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" > password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/> > {code} > We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the > password. However, this seems to cause an issue when we try use Solr in a > Cloud Configuration (using Zookeeper). The error is "Strong key gen and > multiprime gen require at least 1024-bit keysize." Full log attached. > This seems to be due to the hard-coded value of 512 in the > org.apache.solr.util.CryptoKeys$RSAKeyPair class: > {code:java} > public RSAKeyPair() { > KeyPairGenerator keyGen = null; > try { > keyGen = KeyPairGenerator.getInstance("RSA"); > } catch (NoSuchAlgorithmException e) { > throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e); > } > keyGen.initialize(512); > {code} > I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt > it, and now everything seems to work great. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Solr Ref Guide for 6.3
I'll volunteer to release manage the Ref Guide for Solr 6.3. I've reviewed CHANGES.txt, cut some issues, and organized the rest by where I'm guessing they should go: https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List. Please think about what you worked on in 6.3 and try to make some time to update the Ref Guide accordingly. I'm happy to review your content or help you any way I can. We use the TODO list to tell us what needs to be documented - put your initials next to or under an item if you can work on it so we don't overlap efforts. With luck, maybe next time we'll be able to use a new process. But we aren't there yet so I ask for as much of your help as you can give. I intend to make an RC of the Ref Guide by the end of the week (by Friday, Nov 4). I'll update if I am delayed; if you'd like to work on something but need more time than that, please let me know. Thanks, Cassandra - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[ https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623410#comment-15623410 ] Jan Høydahl commented on SOLR-9609: --- My reasoning is that it is not likely something you ever need to change, so using solr.in for overriding looks better than needing to upload stuff to ZK config. And the risk of having different solr.in files is not unique to this setting. We already need SOLR_ZK_HOST to be synchronized as well as probably SSL settings. I think this is in the same neighborhood of deciding the basic wiring of how hosts will talk to eachother. That's why I also think urlScheme could move from being a clusterProp to becoming a sysProp in solr.in, or being auto-resolved from SSL props. > Change hard-coded keysize from 512 to 1024 > -- > > Key: SOLR-9609 > URL: https://issues.apache.org/jira/browse/SOLR-9609 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jeremy Martini >Assignee: Erick Erickson > Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log > > > In order to configure our dataSource without requiring a plaintext password > in the configuration file, we extended JdbcDataSource to create our own > custom implementation. Our dataSource config now looks something like this: > {code:xml} > url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" > password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/> > {code} > We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the > password. However, this seems to cause an issue when we try use Solr in a > Cloud Configuration (using Zookeeper). The error is "Strong key gen and > multiprime gen require at least 1024-bit keysize." Full log attached. > This seems to be due to the hard-coded value of 512 in the > org.apache.solr.util.CryptoKeys$RSAKeyPair class: > {code:java} > public RSAKeyPair() { > KeyPairGenerator keyGen = null; > try { > keyGen = KeyPairGenerator.getInstance("RSA"); > } catch (NoSuchAlgorithmException e) { > throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e); > } > keyGen.initialize(512); > {code} > I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt > it, and now everything seems to work great. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ https://issues.apache.org/jira/browse/SOLR-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623391#comment-15623391 ] Jan Høydahl commented on SOLR-9481: --- Yes, this is currently only on master, and has some intermittent test failures I'm trying to track down before backporting. I got no idea how the changes entry made it to 6.x though, sorry for that [~shalinmangar]. Kevin, thanks for testing! > BasicAuthPlugin should support standalone mode > -- > > Key: SOLR-9481 > URL: https://issues.apache.org/jira/browse/SOLR-9481 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: authentication > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9481.patch, SOLR-9481.patch > > > The BasicAuthPlugin currently only supports SolrCloud, and reads users and > credentials from ZK /security.json > Add support for standalone mode operation -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-6.3-Linux (64bit/jdk-9-ea+140) - Build # 1 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.3-Linux/1/ Java: 64bit/jdk-9-ea+140 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.OverseerTaskQueueTest.testPeekElements Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E3A3816B211942F8:1E8D3B4AF12016E5]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.DistributedQueueTest.testPeekElements(DistributedQueueTest.java:181) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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:367) at java.lang.Thread.run(java.base@9-ea/Thread.java:843) Build Log: [...truncated 11269 lines...] [junit4] Suite: org.apache.solr.cloud.OverseerTaskQueueTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-6.3-Linux/solr/build/solr
[jira] [Commented] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623381#comment-15623381 ] Joel Bernstein commented on SOLR-9077: -- ParallelStream should be fine as it's just a bag of worker nodes. We may not want to support aliases for the FeatureSelectionStream, TextLogitStream and TopicStream. In particular the TopicStream relies on checkpoints which are specific to a physical collection. The FeatureSelectionStream and TextLogitStream probably don't need to support alias and may just complicate things. > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, > SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8384) Windows Start Script when Changing SOLR_SERVER_DIR via -d option
[ https://issues.apache.org/jira/browse/SOLR-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623355#comment-15623355 ] Jan Høydahl commented on SOLR-8384: --- I can agree with you. Looks like the {{-d}} option is designed to work even if the solr/server dir is missing completely, which is not the case for neither bin/solr or bin/solr.cmd currently. bin/solr uses DEFAULT_SERVER_DIR for the run_tool stuff. > Windows Start Script when Changing SOLR_SERVER_DIR via -d option > > > Key: SOLR-8384 > URL: https://issues.apache.org/jira/browse/SOLR-8384 > Project: Solr > Issue Type: Bug > Components: scripts and tools >Affects Versions: 5.3.1 > Environment: Windows >Reporter: Jeremy Anderson >Priority: Trivial > > bin\solr.cmd Requires change of environment variables used in the " REM now > wait to see Solr come online ..." command. Currently this call uses > DEFAULT_SERVER_DIR which is no longer correct when starting SOLR with a > different server directory using the -d command option. > Replace DEFAULT_SERVER_DIR with SOLR_SERVER_DIR so that the proper libraries > are able to be found when checking that SOLR started. > There may be other uses in the script where this issue is present when > starting SOLR from a different directory other than 'server'. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623346#comment-15623346 ] Kevin Risden commented on SOLR-9077: Yea most of the changes are actually test variable changes (COLLECTION -> COLLECTIONORALIAS). Wasn't sure how else to make that change. The important section is confined to CloudSolrStream.getSlices(). The changes I'm concerned with are the FeaturesSectionStream, ParallelStream, TextLogitStream, and TopicStream. These all had getActiveSlices. Not sure the slices HAD to be for a specific collection. Now they should work with all slices from all collections in an alias. Any easier way to view is here: https://github.com/apache/lucene-solr/commit/1e9a285d53ee1a57a0229c4eafdeb8f13c35 > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, > SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623330#comment-15623330 ] Joel Bernstein edited comment on SOLR-9077 at 10/31/16 8:33 PM: Looks good from a quick review, but it's a pretty big patch. It will take a little time to take the whole thing in. If you're feeling comfortable with it feel free to commit, I'm sure this code will get exercised plenty before the 6.4 release. was (Author: joel.bernstein): Looks good from a quick review, but it's a pretty big patch. It will take a little time to take the whole thing in. If you're feeling comfortable with feel free to commit, I'm sure this code will get exercised plenty before the 6.4 release. > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, > SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623330#comment-15623330 ] Joel Bernstein commented on SOLR-9077: -- Looks good from a quick review, but it's a pretty big patch. It will take a little time to take the whole thing in. If you're feeling comfortable with feel free to commit, I'm sure this code will get exercised plenty before the 6.4 release. > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, > SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6962) bin/solr stop -a should complain about missing parameter
[ https://issues.apache.org/jira/browse/SOLR-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623314#comment-15623314 ] Alexandre Rafalovitch commented on SOLR-6962: - I did not (yet) test in and I know there were some script changes in others. Let's leave it for after 6.3 and I will test and commit it. > bin/solr stop -a should complain about missing parameter > > > Key: SOLR-6962 > URL: https://issues.apache.org/jira/browse/SOLR-6962 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > Attachments: SOLR-6962.patch, SOLR-6962v2.patch > > > *bin/solr* has a *-a* option that expects a second parameter. If one is not > provided, it hangs. It should complain and exit just like *-e* option does. > The most common time I hit this is when I try to do *bin/solr stop \-all* and > instead just type *bin/solr stop \-a* as I am more used to give full name > options with double-dash prefix (Unix conventions, I guess). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_102) - Build # 553 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/553/ Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.test Error Message: Captured an uncaught exception in thread: Thread[id=9344, name=SocketProxy-Response-53803:54368, state=RUNNABLE, group=TGRP-HttpPartitionTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=9344, name=SocketProxy-Response-53803:54368, state=RUNNABLE, group=TGRP-HttpPartitionTest] at __randomizedtesting.SeedInfo.seed([2ABD62BCF6D9722A:A2E95D6658251FD2]:0) Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is closed at __randomizedtesting.SeedInfo.seed([2ABD62BCF6D9722A]:0) at org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347) Caused by: java.net.SocketException: Socket is closed at java.net.Socket.setSoTimeout(Socket.java:1137) at org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344) Build Log: [...truncated 11506 lines...] [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_2ABD62BCF6D9722A-001\init-core-data-001 [junit4] 2> 1099310 INFO (SUITE-HttpPartitionTest-seed#[2ABD62BCF6D9722A]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776) [junit4] 2> 1099310 INFO (SUITE-HttpPartitionTest-seed#[2ABD62BCF6D9722A]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /i/c [junit4] 2> 1099312 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 1099346 INFO (Thread-1716) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 1099346 INFO (Thread-1716) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 1099413 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.ZkTestServer start zk server on port:53764 [junit4] 2> 1099772 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 1099775 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema.xml to /configs/conf1/schema.xml [junit4] 2> 1099777 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 1099779 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 1099781 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\protwords.txt to /configs/conf1/protwords.txt [junit4] 2> 1099783 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\currency.xml to /configs/conf1/currency.xml [junit4] 2> 1099784 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\enumsConfig.xml to /configs/conf1/enumsConfig.xml [junit4] 2> 1099787 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\open-exchange-rates.json to /configs/conf1/open-exchange-rates.json [junit4] 2> 1099788 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\mapping-ISOLatin1Accent.txt to /configs/conf1/mapping-ISOLatin1Accent.txt [junit4] 2> 1099791 INFO (TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] o.a.s.c.AbstractZkTestCase put C:\Users\jen
[jira] [Commented] (SOLR-9623) Disable remote streaming by default
[ https://issues.apache.org/jira/browse/SOLR-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623302#comment-15623302 ] Alexandre Rafalovitch commented on SOLR-9623: - bq. A. Remove this section from all solrconfig.xml and let the Java default of false be the new default +1 on A. I am -0 on B, because each section in solrconfig.xml also contributes to the decision fatigue. My anecdotal survey indicates that many people don't even know that this section is there because they get tired of reading solrconfig.xml before that due to all other sections. > Disable remote streaming by default > --- > > Key: SOLR-9623 > URL: https://issues.apache.org/jira/browse/SOLR-9623 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl > Labels: configset > > As we set more and more config settings suitable for production use, perhaps > it is time to disable remoteStreaming by default, and document how to enable > it. > In all config sets, change into > {code:xml} > multipartUploadLimitInKB="2048000" >formdataUploadLimitInKB="2048" >addHttpRequestToContext="false"/> > {code} > And then consider adding support for it in solr.in.xxx -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ https://issues.apache.org/jira/browse/SOLR-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623301#comment-15623301 ] Kevin Risden commented on SOLR-9481: [~janhoy] - I tested with your steps through Docker and it works. Details: https://gist.github.com/risdenk/bd2c48dea8a5c60d2b7746d8b96c7ac2 > BasicAuthPlugin should support standalone mode > -- > > Key: SOLR-9481 > URL: https://issues.apache.org/jira/browse/SOLR-9481 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: authentication > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9481.patch, SOLR-9481.patch > > > The BasicAuthPlugin currently only supports SolrCloud, and reads users and > credentials from ZK /security.json > Add support for standalone mode operation -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9665) Facet Values Sort Order: Add 3rd choice: Numeric Sort
[ https://issues.apache.org/jira/browse/SOLR-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623297#comment-15623297 ] Luke P Warwick commented on SOLR-9665: -- another example: We have a facet who's values go from the 70's to the 120s (width of skis). The values end up looking like this: Brake Width (mm) 100 (7) 110 (9) 115 (6) 120 (3) 74 (2) 80 (1) 85 (1) 90 (9) 93 (1) 95 (1) Facets like this EnumField doesn't work well on since the values aren't always static and EnumField requires that. > Facet Values Sort Order: Add 3rd choice: Numeric Sort > - > > Key: SOLR-9665 > URL: https://issues.apache.org/jira/browse/SOLR-9665 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: faceting >Reporter: Luke P Warwick > > As a person, I need facet values to be in predictable, intuitive spots so > that I can quickly and easily find the values that are appropriate to me. > Problem Statement: Today Solr has two default facet sort orders, neither of > which provides predictable, intuitive facet value orders for people when the > values start with numbers. > Goal: Address the problem where index sorts facet values how a computer would > rather than how a human would. This is very problematic for E-commerce > facets like 'size' and 'tire width' > Acceptance Criteria: > 1. Sorts facet values numerically from lowest to highest > 2. Works with both numeric and string fields (thus working on values that > include letters... 25 mm, 30 waist, 32 Waist, 4 Petite) > 3. If facet values don't start with a number, they are sorted alphabetically, > after all values that do start with a number > 4. If facet values are equal numerically, sort the numerically equal values > alphabetically. Example: 10,10 Petite,10 Tall,12, Petite, 12 Tall > 5. Integers and Floats are supported (even if string field) > Examples: > Women's Pants Sizes: > 8 > 8 Tall > 10 > 10 Petite > 10 Tall > 12 > 12 Tall > 14 Petite > 26 Waist > 28 Waist > 30 Waist > One Size > Bike Wheel Sizes: > 20 Inches > 24 Inches > 26 Inches > 27 Inches > 27.5 Inches > 27.5+ Inches > 29 Inches > 650c > 700c -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623224#comment-15623224 ] Markus Jelsma commented on SOLR-1485: - This is indeed the case but there is still no PayloadQParserPlugin, probably for the reason that there is also no Similarity implementation taking care of payload scoring. We have and use such a plugin and can provide it, and a BM25 similarity where the payload is directly used for scoring in the basic cases. But payloads can be used for much fancier applications, so would would Solr want to support? Without a similarity, the parser is useless. > PayloadTermQuery support > > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Fix For: 6.0 > > Attachments: PayloadTermQueryPlugin.java > > > Solr currently has no support for Lucene's PayloadTermQuery, yet it has > support for indexing payloads. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 6.3.0 RC2
+1 Smoke tester is happy: SUCCESS! [0:24:53.709200] Docs, changes and javadocs look good. -- Steve www.lucidworks.com > On Oct 31, 2016, at 2:28 PM, Shalin Shekhar Mangar wrote: > > Please vote for the second release candidate for Lucene/Solr 6.3.0 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/ > > You can run the smoke tester directly with this command: > python3 -u dev-tools/scripts/smokeTestRelease.py > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/ > > Smoke tester passed for me: > SUCCESS! [0:35:05.847870] > > Here's my +1 to release. > > -- > Regards, > Shalin Shekhar Mangar. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_102) - Build # 6217 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6217/ Java: 32bit/jdk1.8.0_102 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.security.BasicAuthStandaloneTest.testBasicAuth Error Message: Invalid jsonError 401 HTTP ERROR: 401 Problem accessing /solr/admin/authentication. Reason: Bad credentials http://eclipse.org/jetty";>Powered by Jetty:// 9.3.8.v20160314 Stack Trace: java.lang.AssertionError: Invalid json Error 401 HTTP ERROR: 401 Problem accessing /solr/admin/authentication. Reason: Bad credentials http://eclipse.org/jetty";>Powered by Jetty:// 9.3.8.v20160314 at __randomizedtesting.SeedInfo.seed([B77EE5D7571E82C6:B1093C5F34D01BC]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.security.BasicAuthIntegrationTest.verifySecurityStatus(BasicAuthIntegrationTest.java:256) at org.apache.solr.security.BasicAuthIntegrationTest.verifySecurityStatus(BasicAuthIntegrationTest.java:237) at org.apache.solr.security.BasicAuthStandaloneTest.testBasicAuth(BasicAuthStandaloneTest.java:106) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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.
[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9077: --- Attachment: SOLR-9077.patch Remove some unused imports > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, > SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] Release Lucene/Solr 6.3.0 RC2
Please vote for the second release candidate for Lucene/Solr 6.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/ You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/ Smoke tester passed for me: SUCCESS! [0:35:05.847870] Here's my +1 to release. -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7438) UnifiedHighlighter
[ https://issues.apache.org/jira/browse/LUCENE-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622882#comment-15622882 ] Yonik Seeley commented on LUCENE-7438: -- Is this usable from Solr yet, or should a new issue be opened for that? A quick grep suggests there's nothing yet: {code} find solr -type f | xargs grep -i UnifiedHighlighter {code} > UnifiedHighlighter > -- > > Key: LUCENE-7438 > URL: https://issues.apache.org/jira/browse/LUCENE-7438 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Affects Versions: 6.2 >Reporter: Timothy M. Rodriguez >Assignee: David Smiley > Fix For: 6.3 > > Attachments: LUCENE-7438.patch, LUCENE_7438_UH_benchmark.patch, > LUCENE_7438_UH_benchmark.patch, LUCENE_7438_UH_small_changes.patch > > > The UnifiedHighlighter is an evolution of the PostingsHighlighter that is > able to highlight using offsets in either postings, term vectors, or from > analysis (a TokenStream). Lucene’s existing highlighters are mostly > demarcated along offset source lines, whereas here it is unified -- hence > this proposed name. In this highlighter, the offset source strategy is > separated from the core highlighting functionalty. The UnifiedHighlighter > further improves on the PostingsHighlighter’s design by supporting accurate > phrase highlighting using an approach similar to the standard highlighter’s > WeightedSpanTermExtractor. The next major improvement is a hybrid offset > source strategythat utilizes postings and “light” term vectors (i.e. just the > terms) for highlighting multi-term queries (wildcards) without resorting to > analysis. Phrase highlighting and wildcard highlighting can both be disabled > if you’d rather highlight a little faster albeit not as accurately reflecting > the query. > We’ve benchmarked an earlier version of this highlighter comparing it to the > other highlighters and the results were exciting! It’s tempting to share > those results but it’s definitely due for another benchmark, so we’ll work on > that. Performance was the main motivator for creating the UnifiedHighlighter, > as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy > requirements) wasn’t fast enough, even with term vectors along with several > improvements we contributed back, and even after we forked it to highlight in > multiple threads. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9077: --- Attachment: SOLR-9077.patch Fixed issue w/ StatementImpl for JDBC when using alias. > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9077: --- Attachment: SOLR-9077.patch Attaching patch with randomized alias vs collection for JdbcTest, StreamingTest, StreamExpressionTest, and JDBCStreamTest. Tests seem to be passing for me locally. [~joel.bernstein] or [~dpgove] - Can you take a look and see if this is sane? > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch, SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result
[ https://issues.apache.org/jira/browse/SOLR-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622786#comment-15622786 ] Joel Bernstein commented on SOLR-9616: -- Ah just read the above comments, looks like the bug was introduced in 6.1? > Solr throws exception when expand=true on empty result > -- > > Key: SOLR-9616 > URL: https://issues.apache.org/jira/browse/SOLR-9616 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.2.1 >Reporter: Timo Hund >Priority: Critical > Fix For: 6.2.1 > > > When i run a query with expand=true with field collapsing and the result set > is empty an exception is thrown: > solr:8984/solr/core_en/select?&fq={!collapse > field=pid}&expand=true&expand.rows=10 > Produces: > "error":{ > "msg":"Index: 0, Size: 0", > "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat > java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat > java.util.ArrayList.get(ArrayList.java:429)\n\tat > java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat > org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat > org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat > > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat > > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat > > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat > > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat > > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat > java.lang.Thread.run(Thread.java:745)\n", > "code":500}} > Instead i would assume to get an empty result. > Is this a bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result
[ https://issues.apache.org/jira/browse/SOLR-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622780#comment-15622780 ] Joel Bernstein commented on SOLR-9616: -- This is quite a nasty bug. Wondering if this is a recent regression, as the expand component has been around quite a long time in Solr 4. > Solr throws exception when expand=true on empty result > -- > > Key: SOLR-9616 > URL: https://issues.apache.org/jira/browse/SOLR-9616 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.2.1 >Reporter: Timo Hund >Priority: Critical > Fix For: 6.2.1 > > > When i run a query with expand=true with field collapsing and the result set > is empty an exception is thrown: > solr:8984/solr/core_en/select?&fq={!collapse > field=pid}&expand=true&expand.rows=10 > Produces: > "error":{ > "msg":"Index: 0, Size: 0", > "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat > java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat > java.util.ArrayList.get(ArrayList.java:429)\n\tat > java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat > org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat > org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat > > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat > > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat > > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat > > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat > > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat > java.lang.Thread.run(Thread.java:745)\n", > "code":500}} > Instead i would assume to get an empty result. > Is this a bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ https://issues.apache.org/jira/browse/SOLR-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622773#comment-15622773 ] Kevin Risden commented on SOLR-9481: This looks like it was only committed to master. The last commit was from Shalin for the release and only affected CHANGES.txt. > BasicAuthPlugin should support standalone mode > -- > > Key: SOLR-9481 > URL: https://issues.apache.org/jira/browse/SOLR-9481 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: authentication > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9481.patch, SOLR-9481.patch > > > The BasicAuthPlugin currently only supports SolrCloud, and reads users and > credentials from ZK /security.json > Add support for standalone mode operation -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9707) DeleteByQuery forward requests to down replicas and set it in LiR
[ https://issues.apache.org/jira/browse/SOLR-9707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Cheng Mallet updated SOLR-9707: --- Attachment: SOLR-9707.diff > DeleteByQuery forward requests to down replicas and set it in LiR > - > > Key: SOLR-9707 > URL: https://issues.apache.org/jira/browse/SOLR-9707 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Jessica Cheng Mallet > Labels: solrcloud > Attachments: SOLR-9707.diff > > > DeleteByQuery, unlike other requests, does not filter out the down replicas. > Thus, the update is still forwarded to the down replica and fails, and the > leader then sets the replica in LiR. In a cluster where there are lots of > deleteByQuery requests, this can flood the /overseer/queue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[ https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622770#comment-15622770 ] Erick Erickson commented on SOLR-9609: -- [~janhoy] As a sysprop every solr.in.sh file (or whatever) would have to be modified, leaving the chance of one of your N nodes not getting the update. Putting it up on Zookeeper in security.json makes that much less likely. Hmmm, but what about sequencing here? In order to pull it from security.json, we need to be able to connect to Zookeeper. I'm assuming that this is irrelevant for fetching the security.json file from Zookeeper? You see where this is going, if we have to have this value correctly set in order to get data from Zookeeper, then it must go in solr.in.sh.. That said, I don't have a strong opinion here although I slightly lean towards putting this in the security.json file unless that'd be a problem. NOTE: SOLR-9481 appears to have been committed to 6x, so if we choose to put this in security.json we can go forward with this ticket. I've assigned it to myself to not lose track of it, but anyone else who wants to pick it up please feel free. Erick > Change hard-coded keysize from 512 to 1024 > -- > > Key: SOLR-9609 > URL: https://issues.apache.org/jira/browse/SOLR-9609 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jeremy Martini >Assignee: Erick Erickson > Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log > > > In order to configure our dataSource without requiring a plaintext password > in the configuration file, we extended JdbcDataSource to create our own > custom implementation. Our dataSource config now looks something like this: > {code:xml} > url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" > password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/> > {code} > We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the > password. However, this seems to cause an issue when we try use Solr in a > Cloud Configuration (using Zookeeper). The error is "Strong key gen and > multiprime gen require at least 1024-bit keysize." Full log attached. > This seems to be due to the hard-coded value of 512 in the > org.apache.solr.util.CryptoKeys$RSAKeyPair class: > {code:java} > public RSAKeyPair() { > KeyPairGenerator keyGen = null; > try { > keyGen = KeyPairGenerator.getInstance("RSA"); > } catch (NoSuchAlgorithmException e) { > throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e); > } > keyGen.initialize(512); > {code} > I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt > it, and now everything seems to work great. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9707) DeleteByQuery forward requests to down replicas and set it in LiR
Jessica Cheng Mallet created SOLR-9707: -- Summary: DeleteByQuery forward requests to down replicas and set it in LiR Key: SOLR-9707 URL: https://issues.apache.org/jira/browse/SOLR-9707 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: Jessica Cheng Mallet DeleteByQuery, unlike other requests, does not filter out the down replicas. Thus, the update is still forwarded to the down replica and fails, and the leader then sets the replica in LiR. In a cluster where there are lots of deleteByQuery requests, this can flood the /overseer/queue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9623) Disable remote streaming by default
[ https://issues.apache.org/jira/browse/SOLR-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622763#comment-15622763 ] Erik Hatcher commented on SOLR-9623: bq. ... because it's then easy to enable it with a System property. Maybe this could be generalized, such that all settings can correspond to a "solr.some.key" system property override? [maybe with a solr.system.property.resolver=off setting too] Just thinking outloud... > Disable remote streaming by default > --- > > Key: SOLR-9623 > URL: https://issues.apache.org/jira/browse/SOLR-9623 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl > Labels: configset > > As we set more and more config settings suitable for production use, perhaps > it is time to disable remoteStreaming by default, and document how to enable > it. > In all config sets, change into > {code:xml} > multipartUploadLimitInKB="2048000" >formdataUploadLimitInKB="2048" >addHttpRequestToContext="false"/> > {code} > And then consider adding support for it in solr.in.xxx -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-9609) Change hard-coded keysize from 512 to 1024
[ https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-9609: Assignee: Erick Erickson > Change hard-coded keysize from 512 to 1024 > -- > > Key: SOLR-9609 > URL: https://issues.apache.org/jira/browse/SOLR-9609 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jeremy Martini >Assignee: Erick Erickson > Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log > > > In order to configure our dataSource without requiring a plaintext password > in the configuration file, we extended JdbcDataSource to create our own > custom implementation. Our dataSource config now looks something like this: > {code:xml} > url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" > password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/> > {code} > We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the > password. However, this seems to cause an issue when we try use Solr in a > Cloud Configuration (using Zookeeper). The error is "Strong key gen and > multiprime gen require at least 1024-bit keysize." Full log attached. > This seems to be due to the hard-coded value of 512 in the > org.apache.solr.util.CryptoKeys$RSAKeyPair class: > {code:java} > public RSAKeyPair() { > KeyPairGenerator keyGen = null; > try { > keyGen = KeyPairGenerator.getInstance("RSA"); > } catch (NoSuchAlgorithmException e) { > throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e); > } > keyGen.initialize(512); > {code} > I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt > it, and now everything seems to work great. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ https://issues.apache.org/jira/browse/SOLR-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622748#comment-15622748 ] Erick Erickson commented on SOLR-9481: -- Hmmm, can this one be closed now since it's been committed back to 6.3 and 6.x? > BasicAuthPlugin should support standalone mode > -- > > Key: SOLR-9481 > URL: https://issues.apache.org/jira/browse/SOLR-9481 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: authentication > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9481.patch, SOLR-9481.patch > > > The BasicAuthPlugin currently only supports SolrCloud, and reads users and > credentials from ZK /security.json > Add support for standalone mode operation -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias
[ https://issues.apache.org/jira/browse/SOLR-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-9077: --- Attachment: SOLR-9077.patch First pass at trying to make aliases work. There are no tests yet but existing tests pass. This is an approach of refactoring getting slices. > Streaming expressions should support collection alias > - > > Key: SOLR-9077 > URL: https://issues.apache.org/jira/browse/SOLR-9077 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.5.1 >Reporter: Suds >Priority: Minor > Attachments: SOLR-9077.patch > > > Streaming expression in solr does not support collection alias > when I tried to access collection alias I get null pointer exception > issue seems to be related to following code , clusterState.getActiveSlices > returns null > Collection slices = clusterState.getActiveSlices(this.collection); > for(Slice slice : slices) { > } > fix seems to fairly simple , clusterState.getActiveSlices can be made aware > of collection alias. I am not sure what will happen when we have large alias > which has hundred of slices. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9433) SolrCore clean-up logic uses incorrect path to delete dataDir on failure to create a core
[ https://issues.apache.org/jira/browse/SOLR-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-9433: Attachment: SOLR-9433.patch Patch with a fix and test. The data directory needed to be resolved against the coreRootDirectory. > SolrCore clean-up logic uses incorrect path to delete dataDir on failure to > create a core > - > > Key: SOLR-9433 > URL: https://issues.apache.org/jira/browse/SOLR-9433 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.5.2 >Reporter: Evan Sayer > Attachments: SOLR-9433.patch > > > When a core fails to be created for some reason (errant schema or solrconfig > etc.), {{SolrCore.deleteUnloadedCore()}} is called from {{unload()}} in > CoreContainer in order to clean-up the possibly left-over {{dataDir}} and > {{instanceDir}}. The problem is that the CoreDescriptor passed to > {{SolrCore.deleteUnloadedCore()}} will have its value for {{dataDir}} set to > just "data/" unless an explicit {{dataDir}} was specified by the user in the > request to create the core, leading to an attempt to delete simply > {{"data/"}}, which presumably resolves to a non-existent directory under > Solr's home directory or some such. > https://github.com/apache/lucene-solr/blob/branch_5_5/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L974 > https://github.com/apache/lucene-solr/blob/branch_5_5/solr/core/src/java/org/apache/solr/core/SolrCore.java#L2537 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9706) fetchIndex blocks incoming queries when issued on a replica in SolrCloud
Erick Erickson created SOLR-9706: Summary: fetchIndex blocks incoming queries when issued on a replica in SolrCloud Key: SOLR-9706 URL: https://issues.apache.org/jira/browse/SOLR-9706 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.3, trunk Reporter: Erick Erickson This is something of an edge case, but it's perfectly possible to issue a fetchIndex command through the core admin API to a replica in SolrCloud. While the fetch is going on, incoming queries are blocked. Then when the fetch completes, all the queued-up queries execute. In the normal case, this is probably the proper behavior as a fetchIndex during "normal" SolrCloud operation indicates that the replica's index is too far out of date and _shouldn't_ serve queries, this is a special case. Why would one want to do this? Well, in _extremely_ high indexing throughput situations, the additional time taken for the leader forwarding the query on to a follower is too high. So there is an indexing cluster and a search cluster and an external process that issues a fetchIndex to each replica in the search cluster periodiclally. What do people think about an "expert" option for fetchIndex that would cause a replica to behave like the old master/slave days and continue serving queries while the fetchindex was going on? Or another solution? FWIW, here's the stack traces where the blocking is going on (6.3 about). This is not hard to reproduce if you introduce an artificial delay in the fetch command then submit a fetchIndex and try to query. Blocked query thread(s) DefaultSolrCoreState.loci(159) DefaultSolrCoreState.getIndexWriter (104) SolrCore.openNewSearcher(1781) SolrCore.getSearcher(1931) SolrCore.getSearchers(1677) SolrCore.getSearcher(1577) SolrQueryRequestBase.getSearcher(115) QueryComponent.process(308). The stack trace that releases this is DefaultSolrCoreState.createMainIndexWriter(240) DefaultSolrCoreState.changeWriter(203) DefaultSolrCoreState.openIndexWriter(228) // LOCK RELEASED 2 lines later IndexFetcher.fetchLatestIndex(493) (approx, I have debugging code in there. It's in the "finally" clause anyway.) IndexFetcher.fetchLatestIndex(251). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart
[ https://issues.apache.org/jira/browse/LUCENE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622548#comment-15622548 ] Michael McCandless commented on LUCENE-7135: Woops, thanks [~shalinmangar], I fixed it. > Constants check for JRE bitness causes SecurityException under WebStart > --- > > Key: LUCENE-7135 > URL: https://issues.apache.org/jira/browse/LUCENE-7135 > Project: Lucene - Core > Issue Type: Bug > Components: core/other >Affects Versions: 5.5 > Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart) >Reporter: Aaron Madlon-Kay > Fix For: master (7.0), 5.5.4, 6.4 > > Attachments: LUCENE-7135.diff > > > I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are > locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] > uses). > When running under the WebStart security manager, there are two locations > where exceptions are thrown and prevent pretty much all Lucene classes from > initializing. This is true even when we sign everything and specify > {{}}. > # In {{RamUsageEstimator}}, fixed by LUCENE-6923 > # In {{Constants}}, caused by the call > {{System.getProperty("sun.arch.data.model")}} (stack trace below). > {code} > Error: Caused by: java.security.AccessControlException: access denied > ("java.util.PropertyPermission" "sun.arch.data.model" "read") > Error:at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > > Error:at > java.security.AccessController.checkPermission(AccessController.java:884) > Error:at > java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > Error:at > com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) > Error:at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) > Error:at java.lang.System.getProperty(System.java:717) > Error:at org.apache.lucene.util.Constants.(Constants.java:71) > Error:... 34 more > {code} > The latter is still present in the latest version. My patch illustrates one > solution that appears to be working for us. > (This patch, together with a backport of the fix to LUCENE-6923, seems to fix > the issue for our purposes. However if you really wanted to make my day you > could put out a maintenance release of 5.2 with both fixes included.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622553#comment-15622553 ] ASF GitHub Bot commented on SOLR-8593: -- Github user risdenk commented on the issue: https://github.com/apache/lucene-solr/pull/104 @joel-bernstein if you push to the `jira/solr-8593` branch it should update this PR. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart
[ https://issues.apache.org/jira/browse/LUCENE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-7135: --- Fix Version/s: (was: 6.3) 6.4 > Constants check for JRE bitness causes SecurityException under WebStart > --- > > Key: LUCENE-7135 > URL: https://issues.apache.org/jira/browse/LUCENE-7135 > Project: Lucene - Core > Issue Type: Bug > Components: core/other >Affects Versions: 5.5 > Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart) >Reporter: Aaron Madlon-Kay > Fix For: master (7.0), 5.5.4, 6.4 > > Attachments: LUCENE-7135.diff > > > I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are > locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] > uses). > When running under the WebStart security manager, there are two locations > where exceptions are thrown and prevent pretty much all Lucene classes from > initializing. This is true even when we sign everything and specify > {{}}. > # In {{RamUsageEstimator}}, fixed by LUCENE-6923 > # In {{Constants}}, caused by the call > {{System.getProperty("sun.arch.data.model")}} (stack trace below). > {code} > Error: Caused by: java.security.AccessControlException: access denied > ("java.util.PropertyPermission" "sun.arch.data.model" "read") > Error:at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > > Error:at > java.security.AccessController.checkPermission(AccessController.java:884) > Error:at > java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > Error:at > com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) > Error:at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) > Error:at java.lang.System.getProperty(System.java:717) > Error:at org.apache.lucene.util.Constants.(Constants.java:71) > Error:... 34 more > {code} > The latter is still present in the latest version. My patch illustrates one > solution that appears to be working for us. > (This patch, together with a backport of the fix to LUCENE-6923, seems to fix > the issue for our purposes. However if you really wanted to make my day you > could put out a maintenance release of 5.2 with both fixes included.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr issue #104: SOLR-8593 - WIP
Github user risdenk commented on the issue: https://github.com/apache/lucene-solr/pull/104 @joel-bernstein if you push to the `jira/solr-8593` branch it should update this PR. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1143 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1143/ 5 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testResilienceWithDeleteByQueryOnTarget Error Message: Timeout while trying to assert number of documents @ target_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert number of documents @ target_collection at __randomizedtesting.SeedInfo.seed([1C85DE39FCF2EECC:BCE74CA32CAB2B89]:0) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.assertNumDocs(BaseCdcrDistributedZkTest.java:273) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testResilienceWithDeleteByQueryOnTarget(CdcrReplicationDistributedZkTest.java:595) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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.ThreadLe
[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart
[ https://issues.apache.org/jira/browse/LUCENE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622532#comment-15622532 ] Shalin Shekhar Mangar commented on LUCENE-7135: --- This issue is marked for 6.3 but it was not backported to branch_6_3. So the fix version should be 6.4 > Constants check for JRE bitness causes SecurityException under WebStart > --- > > Key: LUCENE-7135 > URL: https://issues.apache.org/jira/browse/LUCENE-7135 > Project: Lucene - Core > Issue Type: Bug > Components: core/other >Affects Versions: 5.5 > Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart) >Reporter: Aaron Madlon-Kay > Fix For: master (7.0), 6.3, 5.5.4 > > Attachments: LUCENE-7135.diff > > > I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are > locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] > uses). > When running under the WebStart security manager, there are two locations > where exceptions are thrown and prevent pretty much all Lucene classes from > initializing. This is true even when we sign everything and specify > {{}}. > # In {{RamUsageEstimator}}, fixed by LUCENE-6923 > # In {{Constants}}, caused by the call > {{System.getProperty("sun.arch.data.model")}} (stack trace below). > {code} > Error: Caused by: java.security.AccessControlException: access denied > ("java.util.PropertyPermission" "sun.arch.data.model" "read") > Error:at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > > Error:at > java.security.AccessController.checkPermission(AccessController.java:884) > Error:at > java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > Error:at > com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) > Error:at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) > Error:at java.lang.System.getProperty(System.java:717) > Error:at org.apache.lucene.util.Constants.(Constants.java:71) > Error:... 34 more > {code} > The latter is still present in the latest version. My patch illustrates one > solution that appears to be working for us. > (This patch, together with a backport of the fix to LUCENE-6923, seems to fix > the issue for our purposes. However if you really wanted to make my day you > could put out a maintenance release of 5.2 with both fixes included.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9311) solrcloud so many connections
[ https://issues.apache.org/jira/browse/SOLR-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622527#comment-15622527 ] Erick Erickson commented on SOLR-9311: -- Kent: Ran across this kind of at random. I know there have been a number of improvements in this area in the 5.5.3 and 6.2 time-frames, with at least one additional improvement coming in the 6.3 (soon to be released) time frame. At any rate, there is very little chance that any fixes would be back-ported to 4.x as development has long been stopped on that branch. So what do you think about closing this ticket? Best, Erick > solrcloud so many connections > - > > Key: SOLR-9311 > URL: https://issues.apache.org/jira/browse/SOLR-9311 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: clients - java >Affects Versions: 4.9 >Reporter: Junfeng Mu > Attachments: CPU.png, connections.png, shards.png > > > firstly, I do not know wether it is a bug or a wrong usage. if this is a > wrong usage, I will opligize to disturb you, and tell me what the wrong usage > is. > We are using Solrj 4.9.1 to connect to a Zookeeper. and the solr server > version is 4.9.0 We are currently using CloudSolrServer as a singleton to > operate index data, and I believe that solrj to zookeeper is a TCP > connection, and zookeeper to solrcloud internal is actually a httpconnection. > we use the zabbix to monitor the solrcloud status, and we deploy solr in > Wildfly(JBOSS), for example the http port is 8180, we find the number that > connecting with solr on port 8180 is so high. for now we find the number can > be around 4000, that is too large.and we find that with the increasing > connections, the query speed become slow. the CPU of the solr sever is > unstable, and the speed to commit new index data becomes slow as well. > besides, the JDK version is 1.7.25 to running solr server. > on the other hand, we have 3 cores with 5 shards, and each shard with one > leader and one replication. now the data account goes to be 100 million, and > it is still growing up. > please see the screenshot of Zabbix in the attachments. > please help me, and looking forward to your reply. > Thanks. > Kent -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ https://issues.apache.org/jira/browse/SOLR-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622503#comment-15622503 ] ASF subversion and git services commented on SOLR-9481: --- Commit 1fe1a54db32b8c27bfae81887cd4d75242090613 in lucene-solr's branch refs/heads/branch_6_3 from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1fe1a54 ] Removing 7.0.0 release section and SOLR-9481 from the CHANGES.txt (cherry picked from commit 2175f6f) > BasicAuthPlugin should support standalone mode > -- > > Key: SOLR-9481 > URL: https://issues.apache.org/jira/browse/SOLR-9481 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: authentication > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9481.patch, SOLR-9481.patch > > > The BasicAuthPlugin currently only supports SolrCloud, and reads users and > credentials from ZK /security.json > Add support for standalone mode operation -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ https://issues.apache.org/jira/browse/SOLR-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622489#comment-15622489 ] ASF subversion and git services commented on SOLR-9481: --- Commit 2175f6fde3d475de01e09d09c83d498551b19dfe in lucene-solr's branch refs/heads/branch_6x from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2175f6f ] Removing 7.0.0 release section and SOLR-9481 from the CHANGES.txt > BasicAuthPlugin should support standalone mode > -- > > Key: SOLR-9481 > URL: https://issues.apache.org/jira/browse/SOLR-9481 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: authentication > Fix For: 6.x, master (7.0) > > Attachments: SOLR-9481.patch, SOLR-9481.patch > > > The BasicAuthPlugin currently only supports SolrCloud, and reads users and > credentials from ZK /security.json > Add support for standalone mode operation -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 6.3.0 RC1
Not good, I'll fix. I added the 7.0 changes to branch_6x by mistake which is why they ended up in branch_6_3 as well. I'll respin and put up another RC for a vote. On Mon, Oct 31, 2016 at 8:24 PM, Steve Rowe wrote: > Smoke tester is happy: SUCCESS! [0:24:04.909195] > > Docs, javadocs and changes look good, except: Solr CHANGES.txt/Changes.html > includes Solr 7.0.0 release notes. Relatively trivial, but I think worthy of > respin, because of the confusion it will cause if left as-is. > > -- > Steve > www.lucidworks.com > >> On Oct 31, 2016, at 10:04 AM, Shalin Shekhar Mangar >> wrote: >> >> Please vote for the first release candidate for Lucene/Solr 6.3.0 >> >> The artifacts can be downloaded from: >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/ >> >> You can run the smoke tester directly with this command: >> python3 -u dev-tools/scripts/smokeTestRelease.py >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/ >> >> Smoke tester passed for me: >> SUCCESS! [0:34:49.638780] >> >> Here's my +1 to release. >> >> -- >> Regards, >> Shalin Shekhar Mangar. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart
[ https://issues.apache.org/jira/browse/LUCENE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622457#comment-15622457 ] ASF subversion and git services commented on LUCENE-7135: - Commit f9e2f0c5b65b389e330a16657396a922e47fce1d in lucene-solr's branch refs/heads/branch_6x from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9e2f0c ] LUCENE-7135: add issue number in CHANGES.txt > Constants check for JRE bitness causes SecurityException under WebStart > --- > > Key: LUCENE-7135 > URL: https://issues.apache.org/jira/browse/LUCENE-7135 > Project: Lucene - Core > Issue Type: Bug > Components: core/other >Affects Versions: 5.5 > Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart) >Reporter: Aaron Madlon-Kay > Fix For: master (7.0), 6.3, 5.5.4 > > Attachments: LUCENE-7135.diff > > > I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are > locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] > uses). > When running under the WebStart security manager, there are two locations > where exceptions are thrown and prevent pretty much all Lucene classes from > initializing. This is true even when we sign everything and specify > {{}}. > # In {{RamUsageEstimator}}, fixed by LUCENE-6923 > # In {{Constants}}, caused by the call > {{System.getProperty("sun.arch.data.model")}} (stack trace below). > {code} > Error: Caused by: java.security.AccessControlException: access denied > ("java.util.PropertyPermission" "sun.arch.data.model" "read") > Error:at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > > Error:at > java.security.AccessController.checkPermission(AccessController.java:884) > Error:at > java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > Error:at > com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) > Error:at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) > Error:at java.lang.System.getProperty(System.java:717) > Error:at org.apache.lucene.util.Constants.(Constants.java:71) > Error:... 34 more > {code} > The latter is still present in the latest version. My patch illustrates one > solution that appears to be working for us. > (This patch, together with a backport of the fix to LUCENE-6923, seems to fix > the issue for our purposes. However if you really wanted to make my day you > could put out a maintenance release of 5.2 with both fixes included.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart
[ https://issues.apache.org/jira/browse/LUCENE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622456#comment-15622456 ] ASF subversion and git services commented on LUCENE-7135: - Commit 2baad4c22d05a1fcc4a09044eae868b6a5bfe1cf in lucene-solr's branch refs/heads/master from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2baad4c ] LUCENE-7135: add issue number in CHANGES.txt > Constants check for JRE bitness causes SecurityException under WebStart > --- > > Key: LUCENE-7135 > URL: https://issues.apache.org/jira/browse/LUCENE-7135 > Project: Lucene - Core > Issue Type: Bug > Components: core/other >Affects Versions: 5.5 > Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart) >Reporter: Aaron Madlon-Kay > Fix For: master (7.0), 6.3, 5.5.4 > > Attachments: LUCENE-7135.diff > > > I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are > locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] > uses). > When running under the WebStart security manager, there are two locations > where exceptions are thrown and prevent pretty much all Lucene classes from > initializing. This is true even when we sign everything and specify > {{}}. > # In {{RamUsageEstimator}}, fixed by LUCENE-6923 > # In {{Constants}}, caused by the call > {{System.getProperty("sun.arch.data.model")}} (stack trace below). > {code} > Error: Caused by: java.security.AccessControlException: access denied > ("java.util.PropertyPermission" "sun.arch.data.model" "read") > Error:at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) > > Error:at > java.security.AccessController.checkPermission(AccessController.java:884) > Error:at > java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > Error:at > com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) > Error:at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) > Error:at java.lang.System.getProperty(System.java:717) > Error:at org.apache.lucene.util.Constants.(Constants.java:71) > Error:... 34 more > {code} > The latter is still present in the latest version. My patch illustrates one > solution that appears to be working for us. > (This patch, together with a backport of the fix to LUCENE-6923, seems to fix > the issue for our purposes. However if you really wanted to make my day you > could put out a maintenance release of 5.2 with both fixes included.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622448#comment-15622448 ] Yonik Seeley commented on SOLR-9681: OK, unless there are objections, I'll move "filter" to be within "domain". > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley reopened SOLR-9681: > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8384) Windows Start Script when Changing SOLR_SERVER_DIR via -d option
[ https://issues.apache.org/jira/browse/SOLR-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622416#comment-15622416 ] Jeremy Anderson commented on SOLR-8384: --- It's been a while since I was messing with this. Essentially I believe I had all the binaries in a different path and was starting SOLR.cmd with the -d command option to direct it to that directory. (I may have been doing this so that I could package SOLR into a different Jetty instance for a prod style deploy) SOLR starts up fine, however the secondary checks performed assume those binaries reside in the Default path which they no longer did. By changing them to use the proper new path of SOLR_SERVER_DIR (set by the -d option if I recall) everything ran fine and as expected. Take a look at :set_server_dir which is what is called when starting with the -d option. Here is where SOLR_SERVER_DIR is set. It may be best to also change the value of DEFAULT_SERVER_DIR here as well. > Windows Start Script when Changing SOLR_SERVER_DIR via -d option > > > Key: SOLR-8384 > URL: https://issues.apache.org/jira/browse/SOLR-8384 > Project: Solr > Issue Type: Bug > Components: scripts and tools >Affects Versions: 5.3.1 > Environment: Windows >Reporter: Jeremy Anderson >Priority: Trivial > > bin\solr.cmd Requires change of environment variables used in the " REM now > wait to see Solr come online ..." command. Currently this call uses > DEFAULT_SERVER_DIR which is no longer correct when starting SOLR with a > different server directory using the -d command option. > Replace DEFAULT_SERVER_DIR with SOLR_SERVER_DIR so that the proper libraries > are able to be found when checking that SOLR started. > There may be other uses in the script where this issue is present when > starting SOLR from a different directory other than 'server'. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - 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 # 941 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/941/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 3 tests failed. FAILED: org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll Error Message: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:40456 within 3 ms Stack Trace: org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:40456 within 3 ms at __randomizedtesting.SeedInfo.seed([6A8EFB4ACCF3C879:1CB0E4398DC46556]:0) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:182) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:111) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:98) at org.apache.solr.cloud.MiniSolrCloudCluster.waitForAllNodes(MiniSolrCloudCluster.java:233) at org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:227) at org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:112) at org.apache.solr.cloud.TestMiniSolrCloudCluster.createMiniSolrCloudCluster(TestMiniSolrCloudCluster.java:90) at org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:276) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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)
[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result
[ https://issues.apache.org/jira/browse/SOLR-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622385#comment-15622385 ] ASF GitHub Bot commented on SOLR-9616: -- GitHub user timohund opened a pull request: https://github.com/apache/lucene-solr/pull/106 SOLR-9616 Return empty result, when expand component is used with empty result set. This pull request: * Add's early return in expand component, when there is nothing to expand * Add's a regression test for SOLR-9616 Since i am very new to the code i am not sure if this has any other side effects, by checking the other tests it looks good for me, but help is appreciated. You can merge this pull request into a Git repository by running: $ git pull https://github.com/timohund/lucene-solr SOLR-9616 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/106.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #106 commit 692dec547d22b366099fc328507a847f1e0cf2c8 Author: Timo Schmidt Date: 2016-10-31T13:53:52Z SOLR-9616 Return empty result, when expand component is used with empty result set. * Add's early return in expand component, when there is nothing to expand * Add's a regression test for SOLR-9616 > Solr throws exception when expand=true on empty result > -- > > Key: SOLR-9616 > URL: https://issues.apache.org/jira/browse/SOLR-9616 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.2.1 >Reporter: Timo Hund >Priority: Critical > Fix For: 6.2.1 > > > When i run a query with expand=true with field collapsing and the result set > is empty an exception is thrown: > solr:8984/solr/core_en/select?&fq={!collapse > field=pid}&expand=true&expand.rows=10 > Produces: > "error":{ > "msg":"Index: 0, Size: 0", > "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat > java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat > java.util.ArrayList.get(ArrayList.java:429)\n\tat > java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat > org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat > org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat > org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat > > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat > > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProd
[GitHub] lucene-solr pull request #106: SOLR-9616 Return empty result, when expand co...
GitHub user timohund opened a pull request: https://github.com/apache/lucene-solr/pull/106 SOLR-9616 Return empty result, when expand component is used with empty result set. This pull request: * Add's early return in expand component, when there is nothing to expand * Add's a regression test for SOLR-9616 Since i am very new to the code i am not sure if this has any other side effects, by checking the other tests it looks good for me, but help is appreciated. You can merge this pull request into a Git repository by running: $ git pull https://github.com/timohund/lucene-solr SOLR-9616 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/106.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #106 commit 692dec547d22b366099fc328507a847f1e0cf2c8 Author: Timo Schmidt Date: 2016-10-31T13:53:52Z SOLR-9616 Return empty result, when expand component is used with empty result set. * Add's early return in expand component, when there is nothing to expand * Add's a regression test for SOLR-9616 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 6.3.0 RC1
Smoke tester is happy: SUCCESS! [0:24:04.909195] Docs, javadocs and changes look good, except: Solr CHANGES.txt/Changes.html includes Solr 7.0.0 release notes. Relatively trivial, but I think worthy of respin, because of the confusion it will cause if left as-is. -- Steve www.lucidworks.com > On Oct 31, 2016, at 10:04 AM, Shalin Shekhar Mangar wrote: > > Please vote for the first release candidate for Lucene/Solr 6.3.0 > > The artifacts can be downloaded from: > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/ > > You can run the smoke tester directly with this command: > python3 -u dev-tools/scripts/smokeTestRelease.py > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/ > > Smoke tester passed for me: > SUCCESS! [0:34:49.638780] > > Here's my +1 to release. > > -- > Regards, > Shalin Shekhar Mangar. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622328#comment-15622328 ] Kevin Risden commented on SOLR-8593: Avatica 1.9 (and Calcite 1.11) is because this needs avatica-core that doesn't do shading. The shading was causing problems integrating into Solr (forget the exact errors now). I saw that Calcite 1.10 requires Avatica 1.8 so just copied the one offending file for now. Since Avatica 1.9 was just released, I'll switch from the SNAPSHOT to the release and should be able to use 1.11 SNAPSHOT since the compatibility fixes for 1.9 were included for Calcite now. > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein >Assignee: Joel Bernstein > >The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9623) Disable remote streaming by default
[ https://issues.apache.org/jira/browse/SOLR-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622313#comment-15622313 ] David Smiley commented on SOLR-9623: bq. B. Leave the tag in XML files, but change the variable default from true->false +1 to 'B' because it's then easy to enable it with a System property. I think this better supports some people getting started with Solr, so that they don't have to go mucking with solrconfig.xml. > Disable remote streaming by default > --- > > Key: SOLR-9623 > URL: https://issues.apache.org/jira/browse/SOLR-9623 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Jan Høydahl > Labels: configset > > As we set more and more config settings suitable for production use, perhaps > it is time to disable remoteStreaming by default, and document how to enable > it. > In all config sets, change into > {code:xml} > multipartUploadLimitInKB="2048000" >formdataUploadLimitInKB="2048" >addHttpRequestToContext="false"/> > {code} > And then consider adding support for it in solr.in.xxx -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8332) factor HttpShardHandler[Factory]'s url shuffling out into a ReplicaListTransformer class
[ https://issues.apache.org/jira/browse/SOLR-8332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622314#comment-15622314 ] Christine Poerschke commented on SOLR-8332: --- bq. Creating a new instance of {{ReplicaListTransformer}} for each request is wasteful. That is why added the request object as a parameter to each call. This way you can manage with a singleton [#102|https://github.com/apache/lucene-solr/pull/102] supports use of a singleton where possible e.g. {{HttpShardHandlerFactory}}'s shuffling transformer: {code} private final ReplicaListTransformer shufflingReplicaListTransformer = new ShufflingReplicaListTransformer(r); ... ReplicaListTransformer getReplicaListTransformer(final SolrQueryRequest req) { return shufflingReplicaListTransformer; } {code} [#102|https://github.com/apache/lucene-solr/pull/102] also supports use of per-request transformers where required (e.g. [ReplicaListTransformerTest.java#L96-L111|https://github.com/bloomberg/lucene-solr/blob/master-solr-8332/solr/core/src/test/org/apache/solr/handler/component/ReplicaListTransformerTest.java#L96-L111]) so that request param deciphering happens only once per prepDistributed call rather than repeatedly in each transform call. > factor HttpShardHandler[Factory]'s url shuffling out into a > ReplicaListTransformer class > > > Key: SOLR-8332 > URL: https://issues.apache.org/jira/browse/SOLR-8332 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8332.patch, SOLR-8332.patch, SOLR-8332.patch > > > Proposed patch against trunk to follow. No change in behaviour intended. This > would be as a step towards SOLR-6730. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622300#comment-15622300 ] David Smiley commented on SOLR-9681: I think I like "filter" underneath "domain". It's clearer *what* is being filtered -- the domain. Granted that raises the question to users as to what the "domain" is but it's something. > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7531) Remove packing support from FST
[ https://issues.apache.org/jira/browse/LUCENE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-7531: - Attachment: LUCENE-7531.patch Here is a patch. > Remove packing support from FST > --- > > Key: LUCENE-7531 > URL: https://issues.apache.org/jira/browse/LUCENE-7531 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-7531.patch > > > This seems to be only used for the kuromoji dictionaries, but we could easily > rebuild those dictionaries with packing disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] Release Lucene/Solr 6.3.0 RC1
Please vote for the first release candidate for Lucene/Solr 6.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/ You can run the smoke tester directly with this command: python3 -u dev-tools/scripts/smokeTestRelease.py https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/ Smoke tester passed for me: SUCCESS! [0:34:49.638780] Here's my +1 to release. -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622219#comment-15622219 ] Yonik Seeley commented on SOLR-9681: Now that you've made me think about it... I'm definitely on the fence, and perhaps closer to the "just put it in domain" side. Anyone else have thoughts? This is the right time to think about this minor API stuff, and then stick to it for the long haul! "domain" is only for non-narrowing domain changes: - If filtering will be used a lot by itself, then it's simpler not to have to enclose it in an extra "domain" "domain" is for *all* domain changes prior to faceting: - If filtering will primarily be used with things like blockChildren, "domain" will already exist, and it's natural for the additional child filters to go right there. - The *only* "narrowing" way to change the domain (other than faceting itself), is "filter". There are unlikely to be others in the future, and thus having a separate class/distinction at the syntactic level does not seem important. > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622219#comment-15622219 ] Yonik Seeley edited comment on SOLR-9681 at 10/31/16 1:58 PM: -- Now that you've made me think about it... I'm definitely on the fence, and perhaps closer to the "just put it in domain" side. Anyone else have thoughts? This is the right time to think about this minor API stuff, and then stick to it for the long haul! Thoughts about both sides: "domain" is only for non-narrowing domain changes: - If filtering will be used a lot by itself, then it's simpler not to have to enclose it in an extra "domain" "domain" is for *all* domain changes prior to faceting: - If filtering will primarily be used with things like blockChildren, "domain" will already exist, and it's natural for the additional child filters to go right there. - The *only* "narrowing" way to change the domain (other than faceting itself), is "filter". There are unlikely to be others in the future, and thus having a separate class/distinction at the syntactic level does not seem important. was (Author: ysee...@gmail.com): Now that you've made me think about it... I'm definitely on the fence, and perhaps closer to the "just put it in domain" side. Anyone else have thoughts? This is the right time to think about this minor API stuff, and then stick to it for the long haul! "domain" is only for non-narrowing domain changes: - If filtering will be used a lot by itself, then it's simpler not to have to enclose it in an extra "domain" "domain" is for *all* domain changes prior to faceting: - If filtering will primarily be used with things like blockChildren, "domain" will already exist, and it's natural for the additional child filters to go right there. - The *only* "narrowing" way to change the domain (other than faceting itself), is "filter". There are unlikely to be others in the future, and thus having a separate class/distinction at the syntactic level does not seem important. > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1691) Deal with deleting old index files in Windows auto-magicly
[ https://issues.apache.org/jira/browse/SOLR-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622215#comment-15622215 ] Jan Høydahl commented on SOLR-1691: --- Is this a practical problem anymore? I have not seen evidence that people suffer from this, and noone have proiritized working on it last 4 years. CLOSE-candidate? > Deal with deleting old index files in Windows auto-magicly > -- > > Key: SOLR-1691 > URL: https://issues.apache.org/jira/browse/SOLR-1691 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man > > Windows users are frequently confused/frustrated by the size of an index > after making lots of changes/commits because of the way Windows prevents > files with open handles from being deleted. > In Lucene-Java, IndexWriter will attempt to delete any old files whenever it > can, but only on a subsequent change -- we should see if we could add > something to Solr to try and be more proactive about this... > http://old.nabble.com/Delete%2C-commit%2C-optimize-doesn%27t-reduce-index-file-size-to26958067.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7531) Remove packing support from FST
Adrien Grand created LUCENE-7531: Summary: Remove packing support from FST Key: LUCENE-7531 URL: https://issues.apache.org/jira/browse/LUCENE-7531 Project: Lucene - Core Issue Type: Task Reporter: Adrien Grand Priority: Minor This seems to be only used for the kuromoji dictionaries, but we could easily rebuild those dictionaries with packing disabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8998) JSON Facet API child roll-ups
[ https://issues.apache.org/jira/browse/SOLR-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622209#comment-15622209 ] Mikhail Khludnev commented on SOLR-8998: [~ysee...@gmail.com], is it possible to implement {{rollup(type_s:parent)}} which does what {{unique(_root_)}} in a way how {{o.a.s.s.join.BlockJoinFieldFacetAccumulator}} enumerating docset once, without running through per value docsets one by one as it happens with {{unique()}} now? > JSON Facet API child roll-ups > - > > Key: SOLR-8998 > URL: https://issues.apache.org/jira/browse/SOLR-8998 > Project: Solr > Issue Type: New Feature > Components: Facet Module >Reporter: Yonik Seeley > > The JSON Facet API currently has the ability to map between parents and > children ( see http://yonik.com/solr-nested-objects/ ) > This issue is about adding a true rollup ability where parents would take on > derived values from their children. The most important part (and the most > difficult part) will be the external API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8384) Windows Start Script when Changing SOLR_SERVER_DIR via -d option
[ https://issues.apache.org/jira/browse/SOLR-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622201#comment-15622201 ] Jan Høydahl commented on SOLR-8384: --- As I can see that command is correct, it only uses DEFAULT_SERVER_DIR to find the SolrCLI tool, which is then looking for a running Solr over HTTP. Please detail exactly what caused you problems? Did you delete the solr/server directory so the binary could not be found? > Windows Start Script when Changing SOLR_SERVER_DIR via -d option > > > Key: SOLR-8384 > URL: https://issues.apache.org/jira/browse/SOLR-8384 > Project: Solr > Issue Type: Bug > Components: scripts and tools >Affects Versions: 5.3.1 > Environment: Windows >Reporter: Jeremy Anderson >Priority: Trivial > > bin\solr.cmd Requires change of environment variables used in the " REM now > wait to see Solr come online ..." command. Currently this call uses > DEFAULT_SERVER_DIR which is no longer correct when starting SOLR with a > different server directory using the -d command option. > Replace DEFAULT_SERVER_DIR with SOLR_SERVER_DIR so that the proper libraries > are able to be found when checking that SOLR started. > There may be other uses in the script where this issue is present when > starting SOLR from a different directory other than 'server'. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source
[ https://issues.apache.org/jira/browse/SOLR-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622191#comment-15622191 ] Aaron Danielson commented on SOLR-9246: --- The 'Caused by: ...' portion of the error message was never printed for me. My column was using type DECIMAL, but JDBC only understands FLOAT or DOUBLE, so this took some serious time to figure out the issue without a more explicit error message. For what it's worth, it would be really nice if the driver could automatically map column types of DECIMAL to FLOAT. > Errors for Streaming Expressions using JDBC (Oracle) stream source > -- > > Key: SOLR-9246 > URL: https://issues.apache.org/jira/browse/SOLR-9246 > Project: Solr > Issue Type: Bug >Affects Versions: 6.0.1 > Environment: Windows 7 >Reporter: Hui Liu >Assignee: Dennis Gove > Fix For: 6.0.2, 6.1.1, 6.2, master (7.0) > > Attachments: Re Errors for Streaming Expressions using JDBC (Oracle) > stream source.txt, SOLR-9246.patch > > > I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with > ‘Streaming Expression’ by using Oracle jdbc as the > stream source, but got 'null pointer' errors, below is the details on how to > reproduce this error: > 1. create a collection 'document6' which only contain long and string data > type, > schema.xml for Solr collection 'document6': (newly created empty collections > with 2 shards) > === > > > > > docValues="true" /> > precisionStep="0" positionIncrementGap="0"/> > > > > > >omitNorms="true"/> > > > multiValued="false"/> > docValues="true"/> > docValues="true"/> > docValues="true"/> > docValues="true"/> > docValues="true"/> > > document_id > document_id > > 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain > columns whose jdbc type is long and string, > create table document6 > (document_id number(12) not null, > sender_msg_dest varchar2(256), > recip_msg_dest varchar2(256), > document_type varchar2(20), > document_keyvarchar2(100)); > loaded 9 records; > Oracle table 'document6': (newly created Oracle table with 9 records) > = > QA_DOCREP@qlgdb1 > desc document6 > Name Null?Type > - > > DOCUMENT_ID NOT NULL NUMBER(12) > SENDER_MSG_DESTVARCHAR2(256) > RECIP_MSG_DEST VARCHAR2(256) > DOCUMENT_TYPE VARCHAR2(20) > DOCUMENT_KEY VARCHAR2(100) > 3. tried this jdbc streaming expression in my browser, getting the error > stack (see below) > http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT > document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM > document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver") > errors in solr.log > == > 2016-06-23 14:07:02.833 INFO (qtp1389647288-139) [c:document6 s:shard2 > r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request > [document6_shard2_replica1] webapp=/solr path=/stream > params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")} > status=0 QTime=1 > 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2 > r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream > java.lang.NullPointerException > at > org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305) > at > org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64) > at > org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374) > at > org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305) > at > org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167) > at > org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183) > at > org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299) > at > org.
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_102) - Build # 18185 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18185/ Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail Error Message: expected:<200> but was:<404> Stack Trace: java.lang.AssertionError: expected:<200> but was:<404> at __randomizedtesting.SeedInfo.seed([73D32783679D0714:1B6C12A9B70715F8]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140) at org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:294) 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:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462) 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
[jira] [Commented] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622180#comment-15622180 ] Mikhail Khludnev commented on SOLR-9681: ok. Agree. Now it can be seen as {{domain}} executed strictly before filtering and faceting. > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7105) Running Solr as a windows service
[ https://issues.apache.org/jira/browse/SOLR-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622172#comment-15622172 ] Jan Høydahl commented on SOLR-7105: --- Also check out SOLR-5176 for an attractive alternative for providing Windows installer support. Chocolatey is like apt-get and keeps a central registry of installer scripts, typically Powershell, and will install unattended. > Running Solr as a windows service > - > > Key: SOLR-7105 > URL: https://issues.apache.org/jira/browse/SOLR-7105 > Project: Solr > Issue Type: Improvement >Reporter: Varun Thacker > Fix For: 6.0 > > > Since we moved away from shipping a war, it's useful to have scripts to start > Solr as a service. > In 5.0 we already added a script for unix systems, we should also add one for > windows. > The Commons Daemon project seems like a good way to implement it - > http://commons.apache.org/proper/commons-daemon/procrun.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-8986) Windows solr.cmd seems to require -p 8983
[ https://issues.apache.org/jira/browse/SOLR-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-8986. - Resolution: Won't Fix Closing this as it is for an old version of Solr, and people are encouraged to upgrade to 6.x. If anyone feel strongly about including a fix for a potential 5.5.x bugfix-release, then feel free to re-open :-) > Windows solr.cmd seems to require -p 8983 > - > > Key: SOLR-8986 > URL: https://issues.apache.org/jira/browse/SOLR-8986 > Project: Solr > Issue Type: Bug >Reporter: Bill Bell > Attachments: start-solr-on-windows.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-8986) Windows solr.cmd seems to require -p 8983
[ https://issues.apache.org/jira/browse/SOLR-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-8986: -- Comment: was deleted (was: The CHANGES.txt commits were actually for SOLR-8996. Sorry for noise on this ticket.) > Windows solr.cmd seems to require -p 8983 > - > > Key: SOLR-8986 > URL: https://issues.apache.org/jira/browse/SOLR-8986 > Project: Solr > Issue Type: Bug >Reporter: Bill Bell > Attachments: start-solr-on-windows.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-8986) Windows solr.cmd seems to require -p 8983
[ https://issues.apache.org/jira/browse/SOLR-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-8986: -- Comment: was deleted (was: Commit df72df1c58a5884774d003eec2f71c27a4737896 in lucene-solr's branch refs/heads/branch_6x from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df72df1 ] SOLR-8986, SOLR-8925, SOLR-9027: Update CHANGES.txt Conflicts: solr/CHANGES.txt ) > Windows solr.cmd seems to require -p 8983 > - > > Key: SOLR-8986 > URL: https://issues.apache.org/jira/browse/SOLR-8986 > Project: Solr > Issue Type: Bug >Reporter: Bill Bell > Attachments: start-solr-on-windows.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-8986) Windows solr.cmd seems to require -p 8983
[ https://issues.apache.org/jira/browse/SOLR-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-8986: -- Comment: was deleted (was: Commit 62a28dd0c7dc8f41e43d5c37e28c968556b8e9d2 in lucene-solr's branch refs/heads/master from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=62a28dd ] SOLR-8986, SOLR-8925, SOLR-9027: Update CHANGES.txt ) > Windows solr.cmd seems to require -p 8983 > - > > Key: SOLR-8986 > URL: https://issues.apache.org/jira/browse/SOLR-8986 > Project: Solr > Issue Type: Bug >Reporter: Bill Bell > Attachments: start-solr-on-windows.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9681) add filter to any facet
[ https://issues.apache.org/jira/browse/SOLR-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622147#comment-15622147 ] Yonik Seeley commented on SOLR-9681: I could go either way... I was sort of viewing "domain" to be just about non-narrowing domain switches (filter exclusions, parent/child, block join) > add filter to any facet > --- > > Key: SOLR-9681 > URL: https://issues.apache.org/jira/browse/SOLR-9681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9681.patch > > > For the JSON Facet API, we should be able to add a list of filters to any > facet. These would be applied after any domain changes, hence useful for > parent->child mapping that would otherwise match all children of any parent > (SOLR-9510) > The API should also be consistent with "filter" at the top level of the JSON > Request API (examples at http://yonik.com/solr-json-request-api/ ) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-3421) Distributed Search doesn't allow for HTTP Authentication
[ https://issues.apache.org/jira/browse/SOLR-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-3421. - Resolution: Implemented Closing as implemented, as we got built-in Auth with support for SolrCloud in 5.3. We'll also get Auth support for plain old master/slave search with SOLR-9640. > Distributed Search doesn't allow for HTTP Authentication > > > Key: SOLR-3421 > URL: https://issues.apache.org/jira/browse/SOLR-3421 > Project: Solr > Issue Type: New Feature > Components: SearchComponents - other >Affects Versions: 3.6, 4.0-ALPHA > Environment: Sharded solr cluster >Reporter: Michael Della Bitta >Priority: Minor > Labels: auth, distributed_search, ssl > > The distributed search feature allows one to configure the list of shards the > SearchHandler should query and aggregate results from using the "shards" > parameter. Unfortunately, there is no way to configure any sort of > authentication between shards and a distributed search-enabled SearchHandler. > It'd be good to be able to specify an authentication type, auth credentials, > and transport security to allow installations that don't have the benefit of > being protected by a firewall some measure of security. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2240) Basic authentication for stream.url
[ https://issues.apache.org/jira/browse/SOLR-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622139#comment-15622139 ] Jan Høydahl commented on SOLR-2240: --- Is this still something that is desired? This issue is pretty old and without much activity, so if noone steps up, I'll close it as Won't fix. > Basic authentication for stream.url > --- > > Key: SOLR-2240 > URL: https://issues.apache.org/jira/browse/SOLR-2240 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 4.0-ALPHA >Reporter: Jayendra Patil >Priority: Minor > Attachments: SOLR-2240.patch > > > We intend to use stream.url for indexing documents from remote locations > exposed through http. > However, the remote urls are secured and would need basic authentication to > be able access the documents. > The current implementation for stream.url in ContentStreamBase.URLStream does > not support authentication. > The implementation with stream.file would mean to download the files to a > local box and would cause duplicity, whereas stream.body would have indexing > performance issues with the hugh data being transferred over the network. > An approach would be :- > 1. Passing additional authentication parameter e.g. stream.url.auth with the > encoded authentication value - SolrRequestParsers > 2. Setting Authorization request property for the Connection - > ContentStreamBase.URLStream > this.conn.setRequestProperty("Authorization", "Basic " + > encodedauthentication); > Any thoughts ?? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org