[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2577 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2577/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([BFB2B76258017827:B7D2C24E570F502C]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[jira] [Created] (LUCENE-6714) Expose version and resource description in CorruptIndexException and friends
Simon Willnauer created LUCENE-6714: --- Summary: Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-6714: Attachment: LUCENE-6714.patch here is a simple patch Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-7796) Implement a gather support info button
[ https://issues.apache.org/jira/browse/SOLR-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652014#comment-14652014 ] Alexandre Rafalovitch commented on SOLR-7796: - Great idea. Might be also useful to include number of records in each shard. This would give overall data size as well as showing off some dis-balances in routing. Implement a gather support info button Key: SOLR-7796 URL: https://issues.apache.org/jira/browse/SOLR-7796 Project: Solr Issue Type: Improvement Components: web gui Reporter: Shawn Heisey Priority: Minor A gather support info button in the admin UI would be extremely helpful. There are some basic pieces of info that we like to have for problem reports on the user list, so there should be an easy way for a user to gather that info. Some of the more basic bits of info would be easy to include in a single file that's easy to cut/paste -- java version, heap info, core/collection names, directories, and stats, etc. If available, it should include server info like memory, commandline args, ZK info, and possibly disk space. There could be two buttons -- one that gathers smaller info into an XML, JSON, or .properties structure that can be easily cut/paste into an email message, and another that gathers larger info like files for configuration and schema along with the other info (grabbing from zookeeper if running in cloud mode) and packages it into a .zip file. Because the user list eats almost all attachments, we would need to come up with some advice for sharing the zipfile. I hate to ask INFRA for a file sharing service, but that might not be a bad idea. -- 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-7555) Display total space and available space in Admin
[ https://issues.apache.org/jira/browse/SOLR-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652028#comment-14652028 ] Eric Pugh commented on SOLR-7555: - Will submit update tonight! Display total space and available space in Admin Key: SOLR-7555 URL: https://issues.apache.org/jira/browse/SOLR-7555 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 5.1 Reporter: Eric Pugh Assignee: Erik Hatcher Priority: Minor Fix For: 5.3 Attachments: DiskSpaceAwareDirectory.java, SOLR-7555-display_disk_space.patch, SOLR-7555-display_disk_space_v2.patch, SOLR-7555-display_disk_space_v3.patch, SOLR-7555-display_disk_space_v4.patch, SOLR-7555-display_disk_space_v5.patch, SOLR-7555.patch, SOLR-7555.patch, SOLR-7555.patch Frequently I have access to the Solr Admin console, but not the underlying server, and I'm curious how much space remains available. This little patch exposes total Volume size as well as the usable space remaining: !https://monosnap.com/file/VqlReekCFwpK6utI3lP18fbPqrGI4b.png! I'm not sure if this is the best place to put this, as every shard will share the same data, so maybe it should be on the top level Dashboard? Also not sure what to call the fields! -- 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-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-6714: Attachment: LUCENE-6714.patch new patch with some simple test additions to sanity check the things Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch, LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652029#comment-14652029 ] Jack Conradson commented on LUCENE-6417: Sorry, Mike and Uwe, for the delayed response. I was actually on vacation the previous week. I'll fix the pre-commit and make the suggested changes. The ASM did not change at all (other than by mistake :) ), I was just forced to re-organize the ASM generation code into smaller chunks for the Antler 4.5 visitor. Thanks for reviewing the patch! Upgrade ANTLR to version 4.5 Key: LUCENE-6417 URL: https://issues.apache.org/jira/browse/LUCENE-6417 Project: Lucene - Core Issue Type: Improvement Reporter: Jack Conradson Attachments: LUCENE-6471.patch I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several features that will improve the existing grammars. The main improvement would be the allowance of left-hand recursion in grammar rules which will reduce the number of rules significantly for expressions. This change will require some code refactoring to the existing expressions 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] (LUCENE-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652027#comment-14652027 ] Simon Willnauer commented on LUCENE-6714: - Looks good. Can we change resourceDescription/resourceDesc to just be one way for all 3 exceptions? Then they will have a consistent API. I prefer the longer one personally. sure thing! Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch, LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-6706) Support Payload scoring for SpanOrQuery
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652011#comment-14652011 ] ASF subversion and git services commented on LUCENE-6706: - Commit 1693921 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1693921 ] LUCENE-6706: Add PayloadScoreQuery Support Payload scoring for SpanOrQuery --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-Tests-trunk-Java8 - Build # 256 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/256/ 1 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: expected:0 but was:1 Stack Trace: java.lang.AssertionError: expected:0 but was:1 at __randomizedtesting.SeedInfo.seed([29C350392312E065:A1976FE38DEE8D9D]: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.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (LUCENE-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652022#comment-14652022 ] Robert Muir commented on LUCENE-6714: - Looks good. Can we change resourceDescription/resourceDesc to just be one way for all 3 exceptions? Then they will have a consistent API. I prefer the longer one personally. Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-6706) Support Payload scoring for SpanOrQuery
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652023#comment-14652023 ] ASF subversion and git services commented on LUCENE-6706: - Commit 1693924 from [~romseygeek] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693924 ] LUCENE-6706: Add PayloadScoreQuery Support Payload scoring for SpanOrQuery --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13717 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13717/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseSerialGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([9B17B83096A8FC9A:9377CD1C99A6D491]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Updated] (LUCENE-6711) Instead of docCount(), maxDoc() is used for numberOfDocuments in SimilarityBase
[
https://issues.apache.org/jira/browse/LUCENE-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ahmet Arslan updated LUCENE-6711:
-
Attachment: LUCENE-6711.patch
Includes changes to TFIDF and BM25, {{ant clean test}} passes.
Instead of docCount(), maxDoc() is used for numberOfDocuments in
SimilarityBase
---
Key: LUCENE-6711
URL: https://issues.apache.org/jira/browse/LUCENE-6711
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Affects Versions: 5.2.1
Reporter: Ahmet Arslan
Priority: Minor
Fix For: 5.3
Attachments: LUCENE-6711.patch, LUCENE-6711.patch, LUCENE-6711.patch
{{SimilarityBase.java}} has the following line :
{code}
long numberOfDocuments = collectionStats.maxDoc();
{code}
It seems like {{collectionStats.docCount()}}, which returns the total number
of documents that have at least one term for this field, is more appropriate
statistics here.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-7766:
--
Attachment: SOLR-7766.txt
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch, SOLR-7766.txt
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651929#comment-14651929
]
Christine Poerschke commented on SOLR-7766:
---
{{createNodeSet=EMPTY}} it is then. github pull request updated (also rebased
against latest trunk) and also attached patch to this JIRA.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch, SOLR-7766.txt
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7796) Implement a gather support info button
[ https://issues.apache.org/jira/browse/SOLR-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651942#comment-14651942 ] Shawn Heisey commented on SOLR-7796: I saw an update on SOLR-7555, and the issue description got me thinking. If the basic info had a list of cores with the index size, volume size, and free space for each one, that would be really nice. Having a data point on the dashboard (and in the basic support info) for the total disk space consumed by all indexes would be really nice. If we can separately calculate the size of inactive transient cores, that would be very nice. You might be wondering why I would be interested in space information for every core. There have been questions on the mailing list about how to have different cores put their index data on different filesystems, so I know that a few users out there will have that setup. We could put information on the dashboard for volume size and free space for the solr home directory, which would be enough for the vast majority of users. Implement a gather support info button Key: SOLR-7796 URL: https://issues.apache.org/jira/browse/SOLR-7796 Project: Solr Issue Type: Improvement Components: web gui Reporter: Shawn Heisey Priority: Minor A gather support info button in the admin UI would be extremely helpful. There are some basic pieces of info that we like to have for problem reports on the user list, so there should be an easy way for a user to gather that info. Some of the more basic bits of info would be easy to include in a single file that's easy to cut/paste -- java version, heap info, core/collection names, directories, and stats, etc. If available, it should include server info like memory, commandline args, ZK info, and possibly disk space. There could be two buttons -- one that gathers smaller info into an XML, JSON, or .properties structure that can be easily cut/paste into an email message, and another that gathers larger info like files for configuration and schema along with the other info (grabbing from zookeeper if running in cloud mode) and packages it into a .zip file. Because the user list eats almost all attachments, we would need to come up with some advice for sharing the zipfile. I hate to ask INFRA for a file sharing service, but that might not be a bad idea. -- 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-7864) timeAllowed causing ClassCastException
Markus Jelsma created SOLR-7864:
---
Summary: timeAllowed causing ClassCastException
Key: SOLR-7864
URL: https://issues.apache.org/jira/browse/SOLR-7864
Project: Solr
Issue Type: Bug
Affects Versions: 5.2
Reporter: Markus Jelsma
Fix For: 5.3, Trunk
If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
{code}
65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter [
search] – null:java.lang.ClassCastException:
org.apache.solr.response.ResultContext cannot be cast to
org.apache.solr.common.SolrDocumentList
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:497)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
{code}
--
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-6625) Add interceptor API for outgoing calls through HttpSolrClient
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6625: - Summary: Add interceptor API for outgoing calls through HttpSolrClient (was: HttpClient callback in HttpSolrServer) Add interceptor API for outgoing calls through HttpSolrClient - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- 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: 5.3 release
I may have to push the branch by a day or two. There are some more loose ends to be tied up from my side. Sorry for the trouble --Noble On Thu, Jul 30, 2015 at 12:48 PM, Adrien Grand jpou...@gmail.com wrote: +1 to releasing 5.3, and thanks for volunteering! On Mon, Jul 27, 2015 at 10:56 AM, Noble Paul noble.p...@gmail.com wrote: Hi, I would like to volunteer myself as the RM for 5.3 release. I plan to cut the 5.3 release branch by next Monday (03/Aug). -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-6714: Attachment: LUCENE-6714.patch new patch with consistent naming for resourceDescription Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch, LUCENE-6714.patch, LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652043#comment-14652043 ] Robert Muir commented on LUCENE-6714: - +1, thanks! Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch, LUCENE-6714.patch, LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652046#comment-14652046
]
ASF subversion and git services commented on SOLR-5882:
---
Commit 1693926 from m...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1693926 ]
SOLR-5882: introducing local param {!parent score=..}..
fixing ScoreMode.Min for ToParentBlockJoinQuery
fixing ScoreMode parsing exception in ScoreJoinQParserPlugin
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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] (LUCENE-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652029#comment-14652029 ] Jack Conradson edited comment on LUCENE-6417 at 8/3/15 4:13 PM: Sorry, Mike and Uwe, for the delayed response. I was actually on vacation the previous week. I'll fix the pre-commit and make the suggested changes. The ASM did not change at all (other than by mistake :) ), I was just forced to re-organize the ASM generation code into smaller chunks for the Antlr 4.5 visitor. Thanks for reviewing the patch! was (Author: jdconradson): Sorry, Mike and Uwe, for the delayed response. I was actually on vacation the previous week. I'll fix the pre-commit and make the suggested changes. The ASM did not change at all (other than by mistake :) ), I was just forced to re-organize the ASM generation code into smaller chunks for the Antler 4.5 visitor. Thanks for reviewing the patch! Upgrade ANTLR to version 4.5 Key: LUCENE-6417 URL: https://issues.apache.org/jira/browse/LUCENE-6417 Project: Lucene - Core Issue Type: Improvement Reporter: Jack Conradson Attachments: LUCENE-6471.patch I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several features that will improve the existing grammars. The main improvement would be the allowance of left-hand recursion in grammar rules which will reduce the number of rules significantly for expressions. This change will require some code refactoring to the existing expressions 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] (LUCENE-6706) Support Payload scoring for SpanOrQuery
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652047#comment-14652047 ] ASF subversion and git services commented on LUCENE-6706: - Commit 1693927 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1693927 ] LUCENE-6706: Remove deprecated PayloadTermQuery and PayloadNearQuery Support Payload scoring for SpanOrQuery --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-6706) Support Payload scoring for all SpanQueries
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-6706: -- Summary: Support Payload scoring for all SpanQueries (was: Support Payload scoring for SpanOrQuery) Support Payload scoring for all SpanQueries --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Fix For: 5.3 Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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] [Resolved] (LUCENE-6706) Support Payload scoring for all SpanQueries
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved LUCENE-6706. --- Resolution: Fixed Fix Version/s: 5.3 Thanks Jamie! Support Payload scoring for all SpanQueries --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Fix For: 5.3 Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-6706) Support Payload scoring for all SpanQueries
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652052#comment-14652052 ] Jamie Johnson commented on LUCENE-6706: --- Thanks Alan, I really appreciate the quick turn around on this. Support Payload scoring for all SpanQueries --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Fix For: 5.3 Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652055#comment-14652055 ] ASF subversion and git services commented on LUCENE-6714: - Commit 1693929 from [~simonw] in branch 'dev/trunk' [ https://svn.apache.org/r1693929 ] LUCENE-6714: Expose exception details via getters on CorruptedIndex-, IndexTooOld-, IndexTooOldException Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch, LUCENE-6714.patch, LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-6625) Add interceptor API for outgoing calls through HttpSolrClient
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652057#comment-14652057 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693931 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1693931 ] SOLR-6625: Remove the HttpContext which provides our request Add interceptor API for outgoing calls through HttpSolrClient - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-revert.patch, SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- 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-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652059#comment-14652059 ] ASF subversion and git services commented on LUCENE-6714: - Commit 1693932 from [~simonw] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693932 ] LUCENE-6714: Expose exception details via getters on CorruptedIndex-, IndexTooOld-, IndexTooOldException Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch, LUCENE-6714.patch, LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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] [Resolved] (LUCENE-6714) Expose version and resource description in CorruptIndexException and friends
[ https://issues.apache.org/jira/browse/LUCENE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-6714. - Resolution: Fixed Assignee: Simon Willnauer Expose version and resource description in CorruptIndexException and friends Key: LUCENE-6714 URL: https://issues.apache.org/jira/browse/LUCENE-6714 Project: Lucene - Core Issue Type: Improvement Affects Versions: 5.2.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Priority: Minor Fix For: 5.3, Trunk Attachments: LUCENE-6714.patch, LUCENE-6714.patch, LUCENE-6714.patch It would be nice to access the minVersion, maxVersion in IndexTooNewException and IndexTooOldException as well as the resoruce description in CorruptIndexException programmatically. I'd love to use this to support better serialization on top of those exception as well as structured responses from the individual values. -- 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-7771) Classloader problem with solr.XXX class names and jars in SOLR_HOME/lib
[
https://issues.apache.org/jira/browse/SOLR-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey closed SOLR-7771.
--
Resolution: Duplicate
[~iorixxx] got this filed before I did, just found that issue.
Classloader problem with solr.XXX class names and jars in SOLR_HOME/lib
-
Key: SOLR-7771
URL: https://issues.apache.org/jira/browse/SOLR-7771
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Environment: C:\Users\elyograg\Downloads\solr-5.2.1java -version
java version 1.8.0_45
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
Reporter: Shawn Heisey
Jars placed in SOLR_HOME/lib seem to be loaded twice, which causes problems
trying to use solr.XX class names in schema.xml.
If the full class name is used, it works.
Steps to recreate on an extracted Solr 5.2.1 download. This was done on
Windows, so I used backslashes as path separators:
{noformat}
bin\solr start
bin\solr create -c foo -d sample_techproducts_configs
bin\solr stop -all
{noformat}
Add the following to server\foo\conf\schema.xml, just before the /schema
end tag:
{noformat}
fieldType name=icu_test class=solr.TextField
analyzer
tokenizer class=solr.ICUTokenizerFactory/
/analyzer
/fieldType
{noformat}
Create a new directory -- server\solr\lib.
Copy icu4j-54.1.jar and lucene-analyzers-icu-5.2.1.jar from
contrib\analysis-extras to server\solr\lib.
{noformat}
bin\solr start
{noformat}
Note an exception in the logging tab:
java.lang.NoClassDefFoundError:
org/apache/lucene/analysis/icu/segmentation/ICUTokenizer
At this point, if the class name is changed from solr.ICUTokenizerFactory to
org.apache.lucene.analysis.icu.segmentation.ICUTokenizerFactory and solr is
stopped and started, then everything is OK.
--
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: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
Guess bypassing that check and always returning true instead would help confirm that. If that's the case, we should just initialize the timeout to Long.MAX_VALUE and check for that to short-circuit? On Mon, Aug 3, 2015 at 3:50 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Yes, I saw that, but thought it could be the underlying implementation, not the ExitableTermsEnum wrapper. Maybe it's related to the calls to System.nanoTime then... On Mon, Aug 3, 2015 at 3:11 PM, Adrien Grand jpou...@gmail.com wrote: Thanks for sharing the traces, it looks like my intuition was wrong. :) They seem to point to ExitableDirectoryReader$ExitableTermsEnum.next, which checks whether the time is out before delegating. On Mon, Aug 3, 2015 at 7:21 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Thanks Adrien, I'll run the tests with 5.3 snapshot and post the results here. In case this helps, this is the hprof samples output (-Xrunhprof:cpu=samples,depth=3,file=/home/ec2-user/hprof_output.txt) for 4.10.4 and 5.2.1 in my test: Solr 4.10.4: CPU SAMPLES BEGIN (total = 243525) Fri Jul 31 22:29:06 2015 rank self accum count trace method 1 75.07% 75.07% 182812 300523 java.net.PlainSocketImpl.socketAccept 2 4.27% 79.34% 10408 301576 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.decodeMetaData 3 4.15% 83.49% 10108 301585 org.apache.lucene.index.FilteredTermsEnum.docs 4 3.46% 86.95%8419 301582 org.apache.lucene.index.FilteredTermsEnum.next 5 2.49% 89.44%6070 301573 java.net.SocketInputStream.socketRead0 6 1.99% 91.43%4848 301599 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 7 1.98% 93.42%4824 301583 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 8 1.57% 94.99%3824 301589 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 9 1.44% 96.42%3504 301594 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.refillDocs 10 1.09% 97.51%2655 301581 java.nio.Bits.copyToArray 11 0.98% 98.50%2388 301598 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.nextDoc 12 0.62% 99.12%1522 301600 org.apache.lucene.store.DataInput.readVInt 13 0.21% 99.33% 500 301612 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.docs 14 0.07% 99.39% 167 301601 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 15 0.06% 99.45% 139 301619 java.lang.System.identityHashCode 16 0.05% 99.50% 114 301632 org.apache.lucene.codecs.lucene41.ForUtil.readBlock 17 0.04% 99.54% 92 300708 java.util.zip.Inflater.inflateBytes 18 0.03% 99.57% 76 301624 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.loadNextFloorBlock 19 0.03% 99.59% 68 300613 java.lang.ClassLoader.defineClass1 20 0.03% 99.62% 68 301615 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 21 0.03% 99.65% 62 301635 org.apache.solr.search.SolrIndexSearcher.getDocSetNC 22 0.02% 99.66% 41 301664 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 23 0.01% 99.68% 31 301629 org.apache.lucene.util.FixedBitSet.init CPU SAMPLES END Solr 5.2.1: CPU SAMPLES BEGIN (total = 235415) Fri Jul 31 22:42:06 2015 rank self accum count trace method 1 51.38% 51.38% 120954 301291 sun.nio.ch.EPollArrayWrapper.epollWait 2 25.69% 77.07% 60477 301292 sun.nio.ch.ServerSocketChannelImpl.accept0 3 10.59% 87.66% 24923 301369 org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.next 4 2.20% 89.86%5182 301414 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.postings 5 2.01% 91.87%4742 301384 org.apache.lucene.index.FilterLeafReader$FilterTermsEnum.postings 6 1.25% 93.12%2944 301434 java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss 7 1.11% 94.23%2612 301367 org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite 8 0.94% 95.17%2204 301390 org.apache.lucene.util.BitSet.or 9 0.93% 96.10%2190 301383 java.nio.Bits.copyToArray 10 0.78% 96.87%1825 301449 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.refillDocs 11 0.73% 97.60%1717 301378 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 12 0.73% 98.33%1715 301374 org.apache.lucene.util.BitSet.or 13 0.33% 98.66% 787 301387 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 14 0.16% 98.82% 374 301426 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 15 0.10% 98.93% 245 301382 org.apache.lucene.util.BitSet.or 16 0.09% 99.02% 219 301381 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 17 0.09% 99.11% 207 301370 org.apache.lucene.util.BitSet.or 18 0.06% 99.17% 153
[jira] [Comment Edited] (SOLR-7859) Clamp down on use of System.currentTimeMillis
[
https://issues.apache.org/jira/browse/SOLR-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652972#comment-14652972
]
Ramkumar Aiyengar edited comment on SOLR-7859 at 8/4/15 2:38 AM:
-
Attached is a patch to remove most occurrences in solr code (boy there are a
few!) and SuppressForbidden where the usage is legitimate.
There are also a couple of cases where the usage is suspect, but I haven't got
to it as yet. One is around stats, but the more worrying thing is that we use
the wall time recorded as commit data on a commit to check if replication needs
to be done. In IndexFetcher, there is this code:
{code}
if (!forceReplication
IndexDeletionPolicyWrapper.getCommitTimestamp(commit) == latestVersion) {
//master and slave are already in sync just return
LOG.info(Slave in sync with master.);
successfulInstall = true;
return true;
}
{code}
We are checking wall times across machines to check if we are in sync? That
sounds wrong.. Or I am mistaken here? Why can't we just check generations?
Another place below checks both generations and timestamps to see if a full
copy is needed..
{code}
// if the generation of master is older than that of the slave , it means
they are not compatible to be copied
// then a new index directory to be created and all the files need to be
copied
boolean isFullCopyNeeded = IndexDeletionPolicyWrapper
.getCommitTimestamp(commit) = latestVersion
|| commit.getGeneration() = latestGeneration || forceReplication;
{code}
was (Author: andyetitmoves):
Attached is a patch to remove most occurrences in solr code (boy there are a
few!) and SuppressForbidden where the usage is legitimate.
There are also a couple of cases where the usage is suspect, but I haven't got
to it as yet. One is around stats, but the more worrying thing is that we use
the wall time recorded as commit data on a commit to check if replication needs
to be done. In IndexFetcher, there is this code:
{code}
if (!forceReplication
IndexDeletionPolicyWrapper.getCommitTimestamp(commit) == latestVersion) {
//master and slave are already in sync just return
LOG.info(Slave in sync with master.);
successfulInstall = true;
return true;
}
{code}
We are checking wall times across machines to check if we are in sync, that
sounds wrong. Or I am mistaken here?
Clamp down on use of System.currentTimeMillis
-
Key: SOLR-7859
URL: https://issues.apache.org/jira/browse/SOLR-7859
Project: Solr
Issue Type: Improvement
Reporter: Ramkumar Aiyengar
Attachments: SOLR-7859.patch
We did one round of this in SOLR-5734, but more places seem to keep cropping
up. We should do one more round, and start whitelisting places which really
need it using forbidden-apis.
--
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-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652759#comment-14652759
]
Hoss Man commented on LUCENE-6609:
--
thanks for the review adrian.
(running full tests and precommit on 5x now)
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
Attachments: LUCENE-6609.patch
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
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-5.x-Windows (32bit/jdk1.8.0_51) - Build # 4974 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4974/ Java: 32bit/jdk1.8.0_51 -server -XX:+UseG1GC 5 tests failed. FAILED: org.apache.lucene.search.payloads.TestPayloadScoreQuery.testSpanContainingQuery Error Message: Unexpected hit in document 296 Stack Trace: java.lang.AssertionError: Unexpected hit in document 296 at __randomizedtesting.SeedInfo.seed([5A58A589322E17:8964B028249CFB65]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.search.payloads.TestPayloadScoreQuery.checkQuery(TestPayloadScoreQuery.java:66) at org.apache.lucene.search.payloads.TestPayloadScoreQuery.testSpanContainingQuery(TestPayloadScoreQuery.java:152) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.lucene.search.payloads.TestPayloadScoreQuery.testNearQuery Error Message: Unexpected hit in document 296 Stack Trace: java.lang.AssertionError: Unexpected hit in document 296 at __randomizedtesting.SeedInfo.seed([5A58A589322E17:40BA355A8FFBB4DB]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.search.payloads.TestPayloadScoreQuery.checkQuery(TestPayloadScoreQuery.java:66) at org.apache.lucene.search.payloads.TestPayloadScoreQuery.testNearQuery(TestPayloadScoreQuery.java:112) at
[jira] [Commented] (LUCENE-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652757#comment-14652757
]
ASF subversion and git services commented on LUCENE-6609:
-
Commit 1693979 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1693979 ]
LUCENE-6609: Add getSortField impls to many subclasses of FieldCacheSource
which return the most direct SortField implementation
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
Attachments: LUCENE-6609.patch
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
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] [Resolved] (LUCENE-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved LUCENE-6609.
--
Resolution: Fixed
Fix Version/s: Trunk
5.3
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 5.3, Trunk
Attachments: LUCENE-6609.patch
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
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-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652844#comment-14652844
]
ASF subversion and git services commented on LUCENE-6609:
-
Commit 1693987 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693987 ]
LUCENE-6609: Add getSortField impls to many subclasses of FieldCacheSource
which return the most direct SortField implementation (merge r1693979)
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 5.3, Trunk
Attachments: LUCENE-6609.patch
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
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-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5103 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5103/ Java: 32bit/jdk1.8.0_51 -client -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.search.function.SortByFunctionTest.testFieldSortSpecifiedAsFunction Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([44EFE5C0854BAE53:7EBD258F7D3938EF]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:765) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:732) at org.apache.solr.search.function.SortByFunctionTest.testFieldSortSpecifiedAsFunction(SortByFunctionTest.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.UnsupportedOperationException: codec does not support random access ordinals, cannot use selector: MAX docValsImpl: org.apache.lucene.codecs.memory.MemoryDocValuesProducer$9@1a3e743 at
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b24) - Build # 13720 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13720/ Java: 64bit/jdk1.8.0_60-ea-b24 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([6DBB89F8922A4694:65DBFCD49D246E9F]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:374) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Updated] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7855: - Attachment: SOLR-7855.patch v2 of the patch, only minor changes mainly around renaming imports for tests. OverseerCollectionProcessor: separate general task management from collection message handling -- Key: SOLR-7855 URL: https://issues.apache.org/jira/browse/SOLR-7855 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7855.patch, SOLR-7855.patch While working on SOLR-7789, I realized it would be easier if I split up the OverseerCollectionProcessor into two parts: 1) General handling of tasks (work queues, etc) 2) Processing a collection handler request I haven't decided whether the ConfigSet should have its own processor, i.e. OverseerConfigSetProcessor or reuse at least the thread for the OverseerCollectionProcessor, but in either case this refactoring will be helpful. That is, if the ConfigSet processing has its own processing, I can reuse the general handling of tasks part. If the ConfigSet processing reuses the OverseerCollectionProcessing thread, I won't complicate the implementation with ConfigSet operations. -- 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] (LUCENE-6706) Support Payload scoring for all SpanQueries
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reopened LUCENE-6706: -- re-opened due to test failures Support Payload scoring for all SpanQueries --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Fix For: 5.3 Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-5.x-Linux (64bit/jdk1.8.0_60-ea-b24) - Build # 13541 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13541/ Java: 64bit/jdk1.8.0_60-ea-b24 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.search.function.SortByFunctionTest.testFieldSortSpecifiedAsFunction Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([3D6425F20488D812:736E5BDFCFA4EAE]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:765) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:732) at org.apache.solr.search.function.SortByFunctionTest.testFieldSortSpecifiedAsFunction(SortByFunctionTest.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.UnsupportedOperationException: codec does not support random access ordinals, cannot use selector: MAX docValsImpl: org.apache.lucene.codecs.memory.MemoryDocValuesProducer$9@4c18199e
[jira] [Commented] (SOLR-6188) solr.ICUFoldingFilterFactory causes NoClassDefFoundError: o/a/l/a/icu/ICUFoldingFilter
[
https://issues.apache.org/jira/browse/SOLR-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652607#comment-14652607
]
Shawn Heisey commented on SOLR-6188:
I closed SOLR-7771 as a duplicate of this issue.
I'm attempting to get Solr 5.2.1 installed into my dev environment with the
config from my Solr 4.9 install. I have all the extra jars in
${solr.solr.home}/lib.
By updating schema.xml to replace the solr.ICU* class names with the fully
qualified versions, I was able to get Solr to start properly.
I'm using another custom analysis component recompiled with 5.2.1 jars:
https://github.com/solrmarc/CJKFoldingFilter/releases
This component works just fine with solr.CJKFoldingFilter in the class
parameter.
solr.ICUFoldingFilterFactory causes NoClassDefFoundError:
o/a/l/a/icu/ICUFoldingFilter
--
Key: SOLR-6188
URL: https://issues.apache.org/jira/browse/SOLR-6188
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.8.1
Reporter: Ahmet Arslan
Labels: ICUFoldingFilterFactory
Fix For: 4.10
When fully qualified class name is used in schema.xml
{{org.apache.lucene.analysis.icu.ICUFoldingFilterFactory}}
it works. However as documented in confluence and wiki, when
{{solr.ICUFoldingFilterFactory}} is used it throws following exception.
This is true for both released 4.8.1 version and trunk r1604168
following type works :
{code:xml}
fieldType name=folded2 class=solr.TextField
analyzer
tokenizer class=solr.StandardTokenizerFactory/
filter
class=org.apache.lucene.analysis.icu.ICUFoldingFilterFactory/
/analyzer
/fieldType
{code}
this does not :
{code:xml}
fieldType name=folded class=solr.TextField
analyzer
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.ICUFoldingFilterFactory/
/analyzer
/fieldType
{code}
{noformat}
257 [main] ERROR org.apache.solr.core.SolrCore – Error loading
core:java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
org/apache/lucene/analysis/icu/ICUFoldingFilter
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:301)
at
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:190)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:137)
at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1252)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:710)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
at
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
at
org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
at
org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
[jira] [Assigned] (LUCENE-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reassigned LUCENE-6609:
Assignee: Hoss Man
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
Attachments: LUCENE-6609.patch
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
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: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
Yes, I saw that, but thought it could be the underlying implementation, not the ExitableTermsEnum wrapper. Maybe it's related to the calls to System.nanoTime then... On Mon, Aug 3, 2015 at 3:11 PM, Adrien Grand jpou...@gmail.com wrote: Thanks for sharing the traces, it looks like my intuition was wrong. :) They seem to point to ExitableDirectoryReader$ExitableTermsEnum.next, which checks whether the time is out before delegating. On Mon, Aug 3, 2015 at 7:21 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Thanks Adrien, I'll run the tests with 5.3 snapshot and post the results here. In case this helps, this is the hprof samples output (-Xrunhprof:cpu=samples,depth=3,file=/home/ec2-user/hprof_output.txt) for 4.10.4 and 5.2.1 in my test: Solr 4.10.4: CPU SAMPLES BEGIN (total = 243525) Fri Jul 31 22:29:06 2015 rank self accum count trace method 1 75.07% 75.07% 182812 300523 java.net.PlainSocketImpl.socketAccept 2 4.27% 79.34% 10408 301576 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.decodeMetaData 3 4.15% 83.49% 10108 301585 org.apache.lucene.index.FilteredTermsEnum.docs 4 3.46% 86.95%8419 301582 org.apache.lucene.index.FilteredTermsEnum.next 5 2.49% 89.44%6070 301573 java.net.SocketInputStream.socketRead0 6 1.99% 91.43%4848 301599 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 7 1.98% 93.42%4824 301583 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 8 1.57% 94.99%3824 301589 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 9 1.44% 96.42%3504 301594 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.refillDocs 10 1.09% 97.51%2655 301581 java.nio.Bits.copyToArray 11 0.98% 98.50%2388 301598 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.nextDoc 12 0.62% 99.12%1522 301600 org.apache.lucene.store.DataInput.readVInt 13 0.21% 99.33% 500 301612 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.docs 14 0.07% 99.39% 167 301601 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 15 0.06% 99.45% 139 301619 java.lang.System.identityHashCode 16 0.05% 99.50% 114 301632 org.apache.lucene.codecs.lucene41.ForUtil.readBlock 17 0.04% 99.54% 92 300708 java.util.zip.Inflater.inflateBytes 18 0.03% 99.57% 76 301624 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.loadNextFloorBlock 19 0.03% 99.59% 68 300613 java.lang.ClassLoader.defineClass1 20 0.03% 99.62% 68 301615 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 21 0.03% 99.65% 62 301635 org.apache.solr.search.SolrIndexSearcher.getDocSetNC 22 0.02% 99.66% 41 301664 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 23 0.01% 99.68% 31 301629 org.apache.lucene.util.FixedBitSet.init CPU SAMPLES END Solr 5.2.1: CPU SAMPLES BEGIN (total = 235415) Fri Jul 31 22:42:06 2015 rank self accum count trace method 1 51.38% 51.38% 120954 301291 sun.nio.ch.EPollArrayWrapper.epollWait 2 25.69% 77.07% 60477 301292 sun.nio.ch.ServerSocketChannelImpl.accept0 3 10.59% 87.66% 24923 301369 org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.next 4 2.20% 89.86%5182 301414 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.postings 5 2.01% 91.87%4742 301384 org.apache.lucene.index.FilterLeafReader$FilterTermsEnum.postings 6 1.25% 93.12%2944 301434 java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss 7 1.11% 94.23%2612 301367 org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite 8 0.94% 95.17%2204 301390 org.apache.lucene.util.BitSet.or 9 0.93% 96.10%2190 301383 java.nio.Bits.copyToArray 10 0.78% 96.87%1825 301449 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.refillDocs 11 0.73% 97.60%1717 301378 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 12 0.73% 98.33%1715 301374 org.apache.lucene.util.BitSet.or 13 0.33% 98.66% 787 301387 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 14 0.16% 98.82% 374 301426 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 15 0.10% 98.93% 245 301382 org.apache.lucene.util.BitSet.or 16 0.09% 99.02% 219 301381 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 17 0.09% 99.11% 207 301370 org.apache.lucene.util.BitSet.or 18 0.06% 99.17% 153 301416 org.apache.lucene.util.BitSet.or 19 0.06% 99.24% 151 301427 org.apache.lucene.util.BitSet.or 20 0.06% 99.30% 151 301441 org.apache.lucene.store.DataInput.readVInt 21 0.06% 99.36% 147 301389 java.lang.System.identityHashCode 22 0.06% 99.42% 140 301375
Re: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
Thanks for sharing the traces, it looks like my intuition was wrong. :) They seem to point to ExitableDirectoryReader$ExitableTermsEnum.next, which checks whether the time is out before delegating. On Mon, Aug 3, 2015 at 7:21 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Thanks Adrien, I'll run the tests with 5.3 snapshot and post the results here. In case this helps, this is the hprof samples output (-Xrunhprof:cpu=samples,depth=3,file=/home/ec2-user/hprof_output.txt) for 4.10.4 and 5.2.1 in my test: Solr 4.10.4: CPU SAMPLES BEGIN (total = 243525) Fri Jul 31 22:29:06 2015 rank self accum count trace method 1 75.07% 75.07% 182812 300523 java.net.PlainSocketImpl.socketAccept 2 4.27% 79.34% 10408 301576 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.decodeMetaData 3 4.15% 83.49% 10108 301585 org.apache.lucene.index.FilteredTermsEnum.docs 4 3.46% 86.95%8419 301582 org.apache.lucene.index.FilteredTermsEnum.next 5 2.49% 89.44%6070 301573 java.net.SocketInputStream.socketRead0 6 1.99% 91.43%4848 301599 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 7 1.98% 93.42%4824 301583 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 8 1.57% 94.99%3824 301589 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 9 1.44% 96.42%3504 301594 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.refillDocs 10 1.09% 97.51%2655 301581 java.nio.Bits.copyToArray 11 0.98% 98.50%2388 301598 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.nextDoc 12 0.62% 99.12%1522 301600 org.apache.lucene.store.DataInput.readVInt 13 0.21% 99.33% 500 301612 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.docs 14 0.07% 99.39% 167 301601 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 15 0.06% 99.45% 139 301619 java.lang.System.identityHashCode 16 0.05% 99.50% 114 301632 org.apache.lucene.codecs.lucene41.ForUtil.readBlock 17 0.04% 99.54% 92 300708 java.util.zip.Inflater.inflateBytes 18 0.03% 99.57% 76 301624 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.loadNextFloorBlock 19 0.03% 99.59% 68 300613 java.lang.ClassLoader.defineClass1 20 0.03% 99.62% 68 301615 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 21 0.03% 99.65% 62 301635 org.apache.solr.search.SolrIndexSearcher.getDocSetNC 22 0.02% 99.66% 41 301664 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 23 0.01% 99.68% 31 301629 org.apache.lucene.util.FixedBitSet.init CPU SAMPLES END Solr 5.2.1: CPU SAMPLES BEGIN (total = 235415) Fri Jul 31 22:42:06 2015 rank self accum count trace method 1 51.38% 51.38% 120954 301291 sun.nio.ch.EPollArrayWrapper.epollWait 2 25.69% 77.07% 60477 301292 sun.nio.ch.ServerSocketChannelImpl.accept0 3 10.59% 87.66% 24923 301369 org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.next 4 2.20% 89.86%5182 301414 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.postings 5 2.01% 91.87%4742 301384 org.apache.lucene.index.FilterLeafReader$FilterTermsEnum.postings 6 1.25% 93.12%2944 301434 java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss 7 1.11% 94.23%2612 301367 org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite 8 0.94% 95.17%2204 301390 org.apache.lucene.util.BitSet.or 9 0.93% 96.10%2190 301383 java.nio.Bits.copyToArray 10 0.78% 96.87%1825 301449 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.refillDocs 11 0.73% 97.60%1717 301378 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 12 0.73% 98.33%1715 301374 org.apache.lucene.util.BitSet.or 13 0.33% 98.66% 787 301387 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 14 0.16% 98.82% 374 301426 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 15 0.10% 98.93% 245 301382 org.apache.lucene.util.BitSet.or 16 0.09% 99.02% 219 301381 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 17 0.09% 99.11% 207 301370 org.apache.lucene.util.BitSet.or 18 0.06% 99.17% 153 301416 org.apache.lucene.util.BitSet.or 19 0.06% 99.24% 151 301427 org.apache.lucene.util.BitSet.or 20 0.06% 99.30% 151 301441 org.apache.lucene.store.DataInput.readVInt 21 0.06% 99.36% 147 301389 java.lang.System.identityHashCode 22 0.06% 99.42% 140 301375 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 23 0.04% 99.47% 104 301425 org.apache.lucene.util.BitSet.or 24 0.03% 99.50% 76 301423 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 25 0.03% 99.53% 74 301454
[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652674#comment-14652674
]
Nick Coult commented on SOLR-7495:
--
We are having the same problem in Solr 5.2.
Unexpected docvalues type NUMERIC when grouping by a int facet
--
Key: SOLR-7495
URL: https://issues.apache.org/jira/browse/SOLR-7495
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Fabio Batista da Silva
Hey All,
After upgrading from solr 4.10 to 5.1 with solr could
I'm getting a IllegalStateException when i try to facet a int field.
IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
(expected=SORTED). Use UninvertingReader or index with docvalues.
schema.xml
{code}
?xml version=1.0 ?
schema name=schema version=1.2
fields
!-- solar cloud version field --
field name=_version_ type=long indexed=true stored=true/
!-- Common fields --
field name=id type=string indexed=true stored=true
multiValued=false required=true/
field name=index_type type=string indexed=true stored=true
multiValued=false required=true/
field name=year type=int indexed=true stored=true/
field name=model type=string indexed=true stored=true/
field name=year_make_model type=string indexed=true
stored=true/
/fields
!-- Field Types --
types
fieldType name=string class=solr.StrField sortMissingLast=true
/
fieldType name=boolean class=solr.BoolField
sortMissingLast=true/
fieldType name=int class=solr.TrieIntField precisionStep=0
positionIncrementGap=0/
fieldType name=float class=solr.TrieFloatField precisionStep=0
positionIncrementGap=0/
fieldType name=long class=solr.TrieLongField precisionStep=0
positionIncrementGap=0/
fieldType name=double class=solr.TrieDoubleField
precisionStep=0 positionIncrementGap=0/
fieldType name=date class=solr.TrieDateField precisionStep=0
positionIncrementGap=0/
fieldType name=text_ngram class=solr.TextField
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.SynonymFilterFactory
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=text_general class=solr.TextField
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.SynonymFilterFactory
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=location_rpt
class=solr.SpatialRecursivePrefixTreeFieldType geo=true
distErrPct=0.025 maxDistErr=0.09 units=degrees /
/types
uniqueKeyid/uniqueKey
defaultSearchFieldname/defaultSearchField
solrQueryParser defaultOperator=OR/
/schema
{code}
query :
{code}
http://solr.dev:8983/solr/my_collection/select?wt=jsonfl=idfq=index_type:foobargroup=truegroup.field=year_make_modelgroup.facet=truefacet=truefacet.field=year
{code}
Exception :
{code}
ull:org.apache.solr.common.SolrException: Exception during facet.field: year
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
at
org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
at
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
at
[jira] [Updated] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
[ https://issues.apache.org/jira/browse/SOLR-7855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7855: - Attachment: SOLR-7855.patch Here's a patch. Review request: https://reviews.apache.org/r/37057/. Splits up the OverseerCollectionProcessor as follows: - Defines an interface OverseerMessageHandler for handling messages sent to the overseer queues - OverseerCollectionMessageHandler handles collection related messages (i.e. this is just the message handling code from the old OverseerCollectionProcessor code) - OverseerProcessor is the task management related code from the old OverseerCollectionProcessor - OverseerProcessor.OverseerMessageHandlerSelector is an interface for selecting an OverseerMessageHandler for an incoming message. This would allows us to handle multiple types of message (e.g. Collection / ConfigSet) with the same OverseerProcessor - OverseerCollectionProcessor is now just an OverseerProcessor with an OverseerMessageHandlerSelector that always selects an OverseerCollectionMessageHandler for processing. One complication is with prioritizeOverseerNodes, which doesn't really fit into this new model or the existing model (it doesn't really have anything to do directly with collections AFAICT, though the CollectionProcessor handles messages about it). This should probably be moved somewhere else and is a pain because both the OverseerProcessor (before running the task loop) and the CollectionMessageHandler (to respond to ADDROLE ops) call it. For now I moved the code to an OverseerNodePrioritizer that is passed into both those objects, though I'm open for suggestions there. Otherwise, just some renaming of imports from OverseerCollectionProcessor to OverseerCollectionMessageHandler. I was originally going to put all the new classes in the cloud.overseer package but there are some package-level info that is needed and for some reason, all the overseer related code isn't there. I'm okay with moving everything there if that's what we want to do. This patch should have no effect on end users. OverseerCollectionProcessor: separate general task management from collection message handling -- Key: SOLR-7855 URL: https://issues.apache.org/jira/browse/SOLR-7855 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Gregory Chanan Assignee: Gregory Chanan Attachments: SOLR-7855.patch While working on SOLR-7789, I realized it would be easier if I split up the OverseerCollectionProcessor into two parts: 1) General handling of tasks (work queues, etc) 2) Processing a collection handler request I haven't decided whether the ConfigSet should have its own processor, i.e. OverseerConfigSetProcessor or reuse at least the thread for the OverseerCollectionProcessor, but in either case this refactoring will be helpful. That is, if the ConfigSet processing has its own processing, I can reuse the general handling of tasks part. If the ConfigSet processing reuses the OverseerCollectionProcessing thread, I won't complicate the implementation with ConfigSet operations. -- 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-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-6609:
-
Attachment: LUCENE-6609.patch
here's a patch with the changes and some basic tests (both whitebox at the
lucene level and more pragmatic at the solr level)
Only one existing test needed changed in this patch:
TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues was assumed
the sort values in the FieldDoc would be Doubles when using an IntFieldSource
as the basis of the Sort -- to keep the spirit of the original test, I wrapped
that IntFieldSource in a SumFloatFunction.
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
Attachments: LUCENE-6609.patch
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
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: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
I'll run the test removing the ExitableDirectoryReader wrap to check if this is the issue. I'll post my results here. On Mon, Aug 3, 2015 at 6:07 PM, Anshum Gupta ans...@anshumgupta.net wrote: Guess bypassing that check and always returning true instead would help confirm that. If that's the case, we should just initialize the timeout to Long.MAX_VALUE and check for that to short-circuit? On Mon, Aug 3, 2015 at 3:50 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Yes, I saw that, but thought it could be the underlying implementation, not the ExitableTermsEnum wrapper. Maybe it's related to the calls to System.nanoTime then... On Mon, Aug 3, 2015 at 3:11 PM, Adrien Grand jpou...@gmail.com wrote: Thanks for sharing the traces, it looks like my intuition was wrong. :) They seem to point to ExitableDirectoryReader$ExitableTermsEnum.next, which checks whether the time is out before delegating. On Mon, Aug 3, 2015 at 7:21 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Thanks Adrien, I'll run the tests with 5.3 snapshot and post the results here. In case this helps, this is the hprof samples output (-Xrunhprof:cpu=samples,depth=3,file=/home/ec2-user/hprof_output.txt) for 4.10.4 and 5.2.1 in my test: Solr 4.10.4: CPU SAMPLES BEGIN (total = 243525) Fri Jul 31 22:29:06 2015 rank self accum count trace method 1 75.07% 75.07% 182812 300523 java.net.PlainSocketImpl.socketAccept 2 4.27% 79.34% 10408 301576 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.decodeMetaData 3 4.15% 83.49% 10108 301585 org.apache.lucene.index.FilteredTermsEnum.docs 4 3.46% 86.95%8419 301582 org.apache.lucene.index.FilteredTermsEnum.next 5 2.49% 89.44%6070 301573 java.net.SocketInputStream.socketRead0 6 1.99% 91.43%4848 301599 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 7 1.98% 93.42%4824 301583 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 8 1.57% 94.99%3824 301589 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 9 1.44% 96.42%3504 301594 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.refillDocs 10 1.09% 97.51%2655 301581 java.nio.Bits.copyToArray 11 0.98% 98.50%2388 301598 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.nextDoc 12 0.62% 99.12%1522 301600 org.apache.lucene.store.DataInput.readVInt 13 0.21% 99.33% 500 301612 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.docs 14 0.07% 99.39% 167 301601 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 15 0.06% 99.45% 139 301619 java.lang.System.identityHashCode 16 0.05% 99.50% 114 301632 org.apache.lucene.codecs.lucene41.ForUtil.readBlock 17 0.04% 99.54% 92 300708 java.util.zip.Inflater.inflateBytes 18 0.03% 99.57% 76 301624 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.loadNextFloorBlock 19 0.03% 99.59% 68 300613 java.lang.ClassLoader.defineClass1 20 0.03% 99.62% 68 301615 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 21 0.03% 99.65% 62 301635 org.apache.solr.search.SolrIndexSearcher.getDocSetNC 22 0.02% 99.66% 41 301664 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 23 0.01% 99.68% 31 301629 org.apache.lucene.util.FixedBitSet.init CPU SAMPLES END Solr 5.2.1: CPU SAMPLES BEGIN (total = 235415) Fri Jul 31 22:42:06 2015 rank self accum count trace method 1 51.38% 51.38% 120954 301291 sun.nio.ch.EPollArrayWrapper.epollWait 2 25.69% 77.07% 60477 301292 sun.nio.ch.ServerSocketChannelImpl.accept0 3 10.59% 87.66% 24923 301369 org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.next 4 2.20% 89.86%5182 301414 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.postings 5 2.01% 91.87%4742 301384 org.apache.lucene.index.FilterLeafReader$FilterTermsEnum.postings 6 1.25% 93.12%2944 301434 java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss 7 1.11% 94.23%2612 301367 org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite 8 0.94% 95.17%2204 301390 org.apache.lucene.util.BitSet.or 9 0.93% 96.10%2190 301383 java.nio.Bits.copyToArray 10 0.78% 96.87%1825 301449 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.refillDocs 11 0.73% 97.60%1717 301378 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 12 0.73% 98.33%1715 301374 org.apache.lucene.util.BitSet.or 13 0.33% 98.66% 787 301387 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 14 0.16% 98.82% 374 301426 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 15 0.10% 98.93% 245 301382 org.apache.lucene.util.BitSet.or
[jira] [Comment Edited] (SOLR-6188) solr.ICUFoldingFilterFactory causes NoClassDefFoundError: o/a/l/a/icu/ICUFoldingFilter
[
https://issues.apache.org/jira/browse/SOLR-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652607#comment-14652607
]
Shawn Heisey edited comment on SOLR-6188 at 8/3/15 9:48 PM:
I closed SOLR-7771 as a duplicate of this issue.
I'm attempting to get Solr 5.2.1 installed into my dev environment with the
config from my Solr 4.9 install. I have all the extra jars in the lib
directory under my solr home.
By updating schema.xml to replace the solr.ICU* class names with the fully
qualified versions, I was able to get Solr to start properly.
I'm using another custom analysis component recompiled with 5.2.1 jars:
https://github.com/solrmarc/CJKFoldingFilter/releases
This component works just fine with solr.CJKFoldingFilter in the class
parameter.
was (Author: elyograg):
I closed SOLR-7771 as a duplicate of this issue.
I'm attempting to get Solr 5.2.1 installed into my dev environment with the
config from my Solr 4.9 install. I have all the extra jars in
${solr.solr.home}/lib.
By updating schema.xml to replace the solr.ICU* class names with the fully
qualified versions, I was able to get Solr to start properly.
I'm using another custom analysis component recompiled with 5.2.1 jars:
https://github.com/solrmarc/CJKFoldingFilter/releases
This component works just fine with solr.CJKFoldingFilter in the class
parameter.
solr.ICUFoldingFilterFactory causes NoClassDefFoundError:
o/a/l/a/icu/ICUFoldingFilter
--
Key: SOLR-6188
URL: https://issues.apache.org/jira/browse/SOLR-6188
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.8.1
Reporter: Ahmet Arslan
Labels: ICUFoldingFilterFactory
Fix For: 4.10
When fully qualified class name is used in schema.xml
{{org.apache.lucene.analysis.icu.ICUFoldingFilterFactory}}
it works. However as documented in confluence and wiki, when
{{solr.ICUFoldingFilterFactory}} is used it throws following exception.
This is true for both released 4.8.1 version and trunk r1604168
following type works :
{code:xml}
fieldType name=folded2 class=solr.TextField
analyzer
tokenizer class=solr.StandardTokenizerFactory/
filter
class=org.apache.lucene.analysis.icu.ICUFoldingFilterFactory/
/analyzer
/fieldType
{code}
this does not :
{code:xml}
fieldType name=folded class=solr.TextField
analyzer
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.ICUFoldingFilterFactory/
/analyzer
/fieldType
{code}
{noformat}
257 [main] ERROR org.apache.solr.core.SolrCore – Error loading
core:java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
org/apache/lucene/analysis/icu/ICUFoldingFilter
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:301)
at
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:190)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:137)
at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1252)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:710)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
at
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
at
org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
at
org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
at
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.8.0) - Build # 2530 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2530/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly Error Message: should have terminated early (searcher.reader=StandardDirectoryReader(segments_q:104 _u(5.3.0):C7)) Stack Trace: java.lang.AssertionError: should have terminated early (searcher.reader=StandardDirectoryReader(segments_q:104 _u(5.3.0):C7)) at __randomizedtesting.SeedInfo.seed([B7A31D1CF6052036:9638A7AE573F6EB1]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.search.TestEarlyTerminatingSortingCollector.testTerminatedEarly(TestEarlyTerminatingSortingCollector.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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 7718 lines...] [junit4] Suite: org.apache.lucene.search.TestEarlyTerminatingSortingCollector [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestEarlyTerminatingSortingCollector -Dtests.method=testTerminatedEarly -Dtests.seed=B7A31D1CF6052036 -Dtests.slow=true -Dtests.locale=th_TH_TH_#u-nu-thai -Dtests.timezone=Pacific/Fiji -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.59s J0 |
[jira] [Updated] (SOLR-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: SOLR-5756-trunk.patch Try this. I haven't run tests all the way through, but most of the way. A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Attachments: SOLR-5756-trunk.patch, SOLR-5756-trunk.patch, SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-7859) Clamp down on use of System.currentTimeMillis
[
https://issues.apache.org/jira/browse/SOLR-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramkumar Aiyengar updated SOLR-7859:
Attachment: SOLR-7859.patch
Attached is a patch to remove most occurrences in solr code (boy there are a
few!) and SuppressForbidden where the usage is legitimate.
There are also a couple of cases where the usage is suspect, but I haven't got
to it as yet. One is around stats, but the more worrying thing is that we use
the wall time recorded as commit data on a commit to check if replication needs
to be done. In IndexFetcher, there is this code:
{code}
if (!forceReplication
IndexDeletionPolicyWrapper.getCommitTimestamp(commit) == latestVersion) {
//master and slave are already in sync just return
LOG.info(Slave in sync with master.);
successfulInstall = true;
return true;
}
{code}
We are checking wall times across machines to check if we are in sync, that
sounds wrong. Or I am mistaken here?
Clamp down on use of System.currentTimeMillis
-
Key: SOLR-7859
URL: https://issues.apache.org/jira/browse/SOLR-7859
Project: Solr
Issue Type: Improvement
Reporter: Ramkumar Aiyengar
Attachments: SOLR-7859.patch
We did one round of this in SOLR-5734, but more places seem to keep cropping
up. We should do one more round, and start whitelisting places which really
need it using forbidden-apis.
--
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-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652653#comment-14652653
]
Adrien Grand commented on LUCENE-6609:
--
+1
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
Attachments: LUCENE-6609.patch
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
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-6706) Support Payload scoring for all SpanQueries
[
https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652893#comment-14652893
]
Steve Rowe commented on LUCENE-6706:
Reproduces for me on branch_5x/win7/java8:
[http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4974/]:
{noformat}
[junit4] Suite: org.apache.lucene.search.payloads.TestPayloadScoreQuery
[junit4] 2 NOTE: download the large Jenkins line-docs file by running
'ant get-jenkins-line-docs' in the lucene directory.
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestPayloadScoreQuery -Dtests.method=testSpanContainingQuery
-Dtests.seed=5A58A589322E17 -Dtests.slow=true -Dtests.linedocsfile=e
:/Lucene_data/enwiki.random.lines.txt -Dtests.locale=nl_BE
-Dtests.timezone=US/Samoa -Dtests.asserts=true -Dtests.file.encoding=Cp1252
[junit4] FAILURE 0.12s | TestPayloadScoreQuery.testSpanContainingQuery
[junit4] Throwable #1: java.lang.AssertionError: Unexpected hit in
document 296
[junit4]at
__randomizedtesting.SeedInfo.seed([5A58A589322E17:8964B028249CFB65]:0)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.checkQuery(TestPayloadScoreQuery.java:66)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.testSpanContainingQuery(TestPayloadScoreQuery.java:152)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] 2 NOTE: download the large Jenkins line-docs file by running
'ant get-jenkins-line-docs' in the lucene directory.
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestPayloadScoreQuery -Dtests.method=testNearQuery
-Dtests.seed=5A58A589322E17 -Dtests.slow=true -Dtests.linedocsfile=e:/Lucene_d
ata/enwiki.random.lines.txt -Dtests.locale=nl_BE -Dtests.timezone=US/Samoa
-Dtests.asserts=true -Dtests.file.encoding=Cp1252
[junit4] FAILURE 0.01s | TestPayloadScoreQuery.testNearQuery
[junit4] Throwable #1: java.lang.AssertionError: Unexpected hit in
document 296
[junit4]at
__randomizedtesting.SeedInfo.seed([5A58A589322E17:40BA355A8FFBB4DB]:0)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.checkQuery(TestPayloadScoreQuery.java:66)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.testNearQuery(TestPayloadScoreQuery.java:112)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] 2 NOTE: download the large Jenkins line-docs file by running
'ant get-jenkins-line-docs' in the lucene directory.
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestPayloadScoreQuery -Dtests.method=testOrQuery
-Dtests.seed=5A58A589322E17 -Dtests.slow=true
-Dtests.linedocsfile=e:/Lucene_data/enwiki.random.lines.txt
-Dtests.locale=nl_BE -Dtests.timezone=US/Samoa -Dtests.asserts=true
-Dtests.file.encoding=Cp1252
[junit4] FAILURE 0.01s | TestPayloadScoreQuery.testOrQuery
[junit4] Throwable #1: java.lang.AssertionError: Unexpected hit in
document 292
[junit4]at
__randomizedtesting.SeedInfo.seed([5A58A589322E17:603E139078605B5F]:0)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.checkQuery(TestPayloadScoreQuery.java:66)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.testOrQuery(TestPayloadScoreQuery.java:93)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] 2 NOTE: download the large Jenkins line-docs file by running
'ant get-jenkins-line-docs' in the lucene directory.
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestPayloadScoreQuery -Dtests.method=testTermQuery
-Dtests.seed=5A58A589322E17 -Dtests.slow=true
-Dtests.linedocsfile=e:/Lucene_data/enwiki.random.lines.txt
-Dtests.locale=nl_BE -Dtests.timezone=US/Samoa -Dtests.asserts=true
-Dtests.file.encoding=Cp1252
[junit4] FAILURE 0.01s | TestPayloadScoreQuery.testTermQuery
[junit4] Throwable #1: java.lang.AssertionError: Unexpected hit in
document 292
[junit4]at
__randomizedtesting.SeedInfo.seed([5A58A589322E17:BF4CC9B6B5DEAF7]:0)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.checkQuery(TestPayloadScoreQuery.java:66)
[junit4]at
org.apache.lucene.search.payloads.TestPayloadScoreQuery.testTermQuery(TestPayloadScoreQuery.java:80)
[junit4]at java.lang.Thread.run(Thread.java:745)
[junit4] 2 NOTE: download the large Jenkins line-docs file by running
'ant get-jenkins-line-docs' in the lucene directory.
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestPayloadScoreQuery -Dtests.method=testNestedNearQuery
-Dtests.seed=5A58A589322E17 -Dtests.slow=true
-Dtests.linedocsfile=e:/Lucene_data/enwiki.random.lines.txt
-Dtests.locale=nl_BE -Dtests.timezone=US/Samoa -Dtests.asserts=true
-Dtests.file.encoding=Cp1252
[junit4]
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13723 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13723/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([35924587113964F9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236) at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([35924587113964F9:3DF230AB1E374CF2]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at
Re: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
On Mon, Aug 3, 2015 at 6:07 PM, Anshum Gupta ans...@anshumgupta.net wrote: Guess bypassing that check and always returning true instead would help confirm that. If that's the case, we should just initialize the timeout to Long.MAX_VALUE and check for that to short-circuit? Another possibility is to run queries without a time limit on a reader that isn't wrapped. That could possibly be friendlier to branch prediction with mixed queries (some without timeouts and some with). -Yonik - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6654) KNearestNeighborClassifier not taking in consideration Class ranking
[ https://issues.apache.org/jira/browse/LUCENE-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651678#comment-14651678 ] Alessandro Benedetti commented on LUCENE-6654: -- To make it simple, using this patch before should not cause any conflict, if we keep not protected here( which is better for patch isolation) later a small merge will happen, Which of.course is not a problem! :) KNearestNeighborClassifier not taking in consideration Class ranking Key: LUCENE-6654 URL: https://issues.apache.org/jira/browse/LUCENE-6654 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: classification, knn Attachments: LUCENE-6654.patch Currently the KNN Classifier assign the score for a ClassificationResult, based only on the frequency of the class in the top K results. This is conceptually a simplification. Actually the ranking must take a part. If not this can happen : Top 4 1) Class1 2) Class1 3) Class2 4) Class2 As a result of this Top 4 , both the classes will have the same score. But the expected result is that Class1 has a better score, as the MLT score the documents accordingly. -- 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-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13713 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13713/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseG1GC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout waiting for CDCR replication to complete @source_collection:shard1 Stack Trace: java.lang.RuntimeException: Timeout waiting for CDCR replication to complete @source_collection:shard1 at __randomizedtesting.SeedInfo.seed([21435AB8DC35042:A74408782CD7849]:0) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:732) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:361) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13531 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13531/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: expected:0 but was:1 Stack Trace: java.lang.AssertionError: expected:0 but was:1 at __randomizedtesting.SeedInfo.seed([1C6D70B651683E42:94394F6CFF9453BA]: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.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Updated] (SOLR-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-5882:
---
Description:
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
was:
*TODO* it needs to be updated.
Today BlockJoinParentQParser creates queries with hardcoded _scoring mode_
None:
{code:borderStyle=solid}
protected Query createQuery(Query parentList, Query query) {
return new ToParentBlockJoinQuery(query, getFilter(parentList),
ScoreMode.None);
}
{code}
Analogically BlockJoinChildQParser creates queries with hardcoded _doScores_
false:
{code:borderStyle=solid}
protected Query createQuery(Query parentListQuery, Query query) {
return new ToChildBlockJoinQuery(query, getFilter(parentListQuery), false);
}
{code}
I propose to have ability to configure this scoring options via query syntax.
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent scoreMode=None|Avg|Max|Total}
{code}
For child query:
{code:borderStyle=solid}
{!child of=type:parent doScores=true|false}
{code}
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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] [Resolved] (SOLR-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SOLR-7719. --- Resolution: Fixed Fix Version/s: 5.3 backported to branch 5.x, resolving therefore as fixed. Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Fix For: 5.3, Trunk Attachments: SOLR-7719.patch, SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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-6691) tweak SortingMergePolicy.getSortDescription
[
https://issues.apache.org/jira/browse/LUCENE-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651689#comment-14651689
]
Christine Poerschke commented on LUCENE-6691:
-
Err, relatively basic commit question. In {{CHANGES.txt}} where would this
issue best be placed? I'm thinking 'Changes in Runtime Behavior' or perhaps
'Bug fixes' section?
tweak SortingMergePolicy.getSortDescription
---
Key: LUCENE-6691
URL: https://issues.apache.org/jira/browse/LUCENE-6691
Project: Lucene - Core
Issue Type: Test
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Building tests for SOLR-5730 identified that early termination can be omitted
for sorted segments because the {{LeafReader}} concerned is not a
{{SegmentReader}} - github pull request to illustrate to follow:
* the {{TestEarlyTerminatingSortingCollector.testTerminatedEarly}} test uses
a wrapped reader in the same way as {{SolrIndexSearcher}}
* the {{SortingMergePolicy.getSortDescription}} change (assuming it is a
valid change to make) fixes that particular test only
* {{ExitableDirectoryReader}} and {{UninvertingReader}} wrap could perhaps
also be added in {{LuceneTestCase.wrapReader}} ?
LUCENE-6065 remove foreign readers from merge, fix LeafReader instead.
also concerns SortingMergePolicy.
--
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-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651683#comment-14651683
]
Mikhail Khludnev commented on SOLR-5882:
[~shalinmangar] it fails on upper case, it accepts only Capital and lowercase.
Here it mimics SOLR-6234 behavior. I just didn't find a guide how to do that.
Is there any examples of case insensitive behavior of qparsers?
If you prefer I can rework ScoreModeParser which can make both qparsers case
insensitive for scoremode, it's not a big deal.
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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-7863) Lowercase the CLUSTERPROP command in ZkCLI for consistency
[
https://issues.apache.org/jira/browse/SOLR-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7863:
--
Fix Version/s: Trunk
Lowercase the CLUSTERPROP command in ZkCLI for consistency
--
Key: SOLR-7863
URL: https://issues.apache.org/jira/browse/SOLR-7863
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
Labels: zkcli
Fix For: 5.3, Trunk
Attachments: SOLR-7863.patch
The examples for the zkcli.sh command looks like this
{noformat}
Examples:
zkcli.sh -zkhost localhost:9983 -cmd bootstrap -solrhome /opt/solr
zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd downconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd linkconfig -collection collection1
-confname myconf
zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr
zkcli.sh -zkhost localhost:9983 -cmd put /solr.conf 'conf data'
zkcli.sh -zkhost localhost:9983 -cmd putfile /solr.xml
/User/myuser/solr/solr.xml
zkcli.sh -zkhost localhost:9983 -cmd get /solr.xml
zkcli.sh -zkhost localhost:9983 -cmd getfile /solr.xml solr.xml.file
zkcli.sh -zkhost localhost:9983 -cmd clear /solr
zkcli.sh -zkhost localhost:9983 -cmd list
zkcli.sh -zkhost localhost:9983 -cmd CLUSTERPROP -name urlScheme -val https
{noformat}
It is inconsistent that CLUSTERPROP is uppercase.
--
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-7863) Lowercase the CLUSTERPROP command in ZkCLI for consistency
[
https://issues.apache.org/jira/browse/SOLR-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7863:
--
Labels: zkcli (was: )
Lowercase the CLUSTERPROP command in ZkCLI for consistency
--
Key: SOLR-7863
URL: https://issues.apache.org/jira/browse/SOLR-7863
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
Labels: zkcli
Fix For: 5.3, Trunk
Attachments: SOLR-7863.patch
The examples for the zkcli.sh command looks like this
{noformat}
Examples:
zkcli.sh -zkhost localhost:9983 -cmd bootstrap -solrhome /opt/solr
zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd downconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd linkconfig -collection collection1
-confname myconf
zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr
zkcli.sh -zkhost localhost:9983 -cmd put /solr.conf 'conf data'
zkcli.sh -zkhost localhost:9983 -cmd putfile /solr.xml
/User/myuser/solr/solr.xml
zkcli.sh -zkhost localhost:9983 -cmd get /solr.xml
zkcli.sh -zkhost localhost:9983 -cmd getfile /solr.xml solr.xml.file
zkcli.sh -zkhost localhost:9983 -cmd clear /solr
zkcli.sh -zkhost localhost:9983 -cmd list
zkcli.sh -zkhost localhost:9983 -cmd CLUSTERPROP -name urlScheme -val https
{noformat}
It is inconsistent that CLUSTERPROP is uppercase.
--
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-7863) Lowercase the CLUSTERPROP command in ZkCLI for consistency
[
https://issues.apache.org/jira/browse/SOLR-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7863:
--
Attachment: SOLR-7863.patch
I'm attaching a patch that lowercases the clusterprop cmd but accepts both
upper and lowercase variants for back compat. Also adds error msg for unknown
cmd.
Lowercase the CLUSTERPROP command in ZkCLI for consistency
--
Key: SOLR-7863
URL: https://issues.apache.org/jira/browse/SOLR-7863
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
Labels: zkcli
Fix For: 5.3, Trunk
Attachments: SOLR-7863.patch
The examples for the zkcli.sh command looks like this
{noformat}
Examples:
zkcli.sh -zkhost localhost:9983 -cmd bootstrap -solrhome /opt/solr
zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd downconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd linkconfig -collection collection1
-confname myconf
zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr
zkcli.sh -zkhost localhost:9983 -cmd put /solr.conf 'conf data'
zkcli.sh -zkhost localhost:9983 -cmd putfile /solr.xml
/User/myuser/solr/solr.xml
zkcli.sh -zkhost localhost:9983 -cmd get /solr.xml
zkcli.sh -zkhost localhost:9983 -cmd getfile /solr.xml solr.xml.file
zkcli.sh -zkhost localhost:9983 -cmd clear /solr
zkcli.sh -zkhost localhost:9983 -cmd list
zkcli.sh -zkhost localhost:9983 -cmd CLUSTERPROP -name urlScheme -val https
{noformat}
It is inconsistent that CLUSTERPROP is uppercase.
--
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-7863) Lowercase the CLUSTERPROP command in ZkCLI for consistency
[
https://issues.apache.org/jira/browse/SOLR-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651704#comment-14651704
]
Jan Høydahl commented on SOLR-7863:
---
Also, if an unknown -cmd is issued, the tool just exits without any
message/error.
Lowercase the CLUSTERPROP command in ZkCLI for consistency
--
Key: SOLR-7863
URL: https://issues.apache.org/jira/browse/SOLR-7863
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
Fix For: 5.3
The examples for the zkcli.sh command looks like this
{noformat}
Examples:
zkcli.sh -zkhost localhost:9983 -cmd bootstrap -solrhome /opt/solr
zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd downconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd linkconfig -collection collection1
-confname myconf
zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr
zkcli.sh -zkhost localhost:9983 -cmd put /solr.conf 'conf data'
zkcli.sh -zkhost localhost:9983 -cmd putfile /solr.xml
/User/myuser/solr/solr.xml
zkcli.sh -zkhost localhost:9983 -cmd get /solr.xml
zkcli.sh -zkhost localhost:9983 -cmd getfile /solr.xml solr.xml.file
zkcli.sh -zkhost localhost:9983 -cmd clear /solr
zkcli.sh -zkhost localhost:9983 -cmd list
zkcli.sh -zkhost localhost:9983 -cmd CLUSTERPROP -name urlScheme -val https
{noformat}
It is inconsistent that CLUSTERPROP is uppercase.
--
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-7863) Lowercase the CLUSTERPROP command in ZkCLI for consistency
[
https://issues.apache.org/jira/browse/SOLR-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-7863:
--
Attachment: SOLR-7863.patch
New patch, making all -cmd case insensitive, so you can write {{-cmd LIST}} if
you wish. Will commit this to trunk and 5.x shortly.
Lowercase the CLUSTERPROP command in ZkCLI for consistency
--
Key: SOLR-7863
URL: https://issues.apache.org/jira/browse/SOLR-7863
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
Labels: zkcli
Fix For: 5.3, Trunk
Attachments: SOLR-7863.patch, SOLR-7863.patch
The examples for the zkcli.sh command looks like this
{noformat}
Examples:
zkcli.sh -zkhost localhost:9983 -cmd bootstrap -solrhome /opt/solr
zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd downconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd linkconfig -collection collection1
-confname myconf
zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr
zkcli.sh -zkhost localhost:9983 -cmd put /solr.conf 'conf data'
zkcli.sh -zkhost localhost:9983 -cmd putfile /solr.xml
/User/myuser/solr/solr.xml
zkcli.sh -zkhost localhost:9983 -cmd get /solr.xml
zkcli.sh -zkhost localhost:9983 -cmd getfile /solr.xml solr.xml.file
zkcli.sh -zkhost localhost:9983 -cmd clear /solr
zkcli.sh -zkhost localhost:9983 -cmd list
zkcli.sh -zkhost localhost:9983 -cmd CLUSTERPROP -name urlScheme -val https
{noformat}
It is inconsistent that CLUSTERPROP is uppercase.
--
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-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651629#comment-14651629 ] ASF subversion and git services commented on SOLR-7719: --- Commit 1693867 from [~teofili] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693867 ] SOLR-7719 - backported Suggester component parsing to branch 5.x Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Fix For: Trunk Attachments: SOLR-7719.patch, SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- 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-6654) KNearestNeighborClassifier not taking in consideration Class ranking
[ https://issues.apache.org/jira/browse/LUCENE-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651666#comment-14651666 ] Tommaso Teofili commented on LUCENE-6654: - I've reviewed the patch and it looks good, thanks Alessandro. Just a minor thing about some fields / methods being marked as _protected_ while they could be _private_, this is usually much better for information hiding and keeping the API as compact as possible. KNearestNeighborClassifier not taking in consideration Class ranking Key: LUCENE-6654 URL: https://issues.apache.org/jira/browse/LUCENE-6654 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: classification, knn Attachments: LUCENE-6654.patch Currently the KNN Classifier assign the score for a ClassificationResult, based only on the frequency of the class in the top K results. This is conceptually a simplification. Actually the ranking must take a part. If not this can happen : Top 4 1) Class1 2) Class1 3) Class2 4) Class2 As a result of this Top 4 , both the classes will have the same score. But the expected result is that Class1 has a better score, as the MLT score the documents accordingly. -- 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-7863) Lowercase the CLUSTERPROP command in ZkCLI for consistency
Jan Høydahl created SOLR-7863:
-
Summary: Lowercase the CLUSTERPROP command in ZkCLI for consistency
Key: SOLR-7863
URL: https://issues.apache.org/jira/browse/SOLR-7863
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
Fix For: 5.3
The examples for the zkcli.sh command looks like this
{noformat}
Examples:
zkcli.sh -zkhost localhost:9983 -cmd bootstrap -solrhome /opt/solr
zkcli.sh -zkhost localhost:9983 -cmd upconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd downconfig -confdir
/opt/solr/collection1/conf -confname myconf
zkcli.sh -zkhost localhost:9983 -cmd linkconfig -collection collection1
-confname myconf
zkcli.sh -zkhost localhost:9983 -cmd makepath /apache/solr
zkcli.sh -zkhost localhost:9983 -cmd put /solr.conf 'conf data'
zkcli.sh -zkhost localhost:9983 -cmd putfile /solr.xml
/User/myuser/solr/solr.xml
zkcli.sh -zkhost localhost:9983 -cmd get /solr.xml
zkcli.sh -zkhost localhost:9983 -cmd getfile /solr.xml solr.xml.file
zkcli.sh -zkhost localhost:9983 -cmd clear /solr
zkcli.sh -zkhost localhost:9983 -cmd list
zkcli.sh -zkhost localhost:9983 -cmd CLUSTERPROP -name urlScheme -val https
{noformat}
It is inconsistent that CLUSTERPROP is uppercase.
--
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-6654) KNearestNeighborClassifier not taking in consideration Class ranking
[ https://issues.apache.org/jira/browse/LUCENE-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651672#comment-14651672 ] Alessandro Benedetti commented on LUCENE-6654: -- Hi Tommaso! The reason for that is related the fact that that class is involved also with another issue ( the document classifier one) But I agree with you, in isolation for this issue they should not be protected. When you take a look to the Document Classifier one, they overlap a little bit, this class should be merged ( basically i put this in the most straighforward way). When you take a look to the other you will see :) KNearestNeighborClassifier not taking in consideration Class ranking Key: LUCENE-6654 URL: https://issues.apache.org/jira/browse/LUCENE-6654 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: classification, knn Attachments: LUCENE-6654.patch Currently the KNN Classifier assign the score for a ClassificationResult, based only on the frequency of the class in the top K results. This is conceptually a simplification. Actually the ranking must take a part. If not this can happen : Top 4 1) Class1 2) Class1 3) Class2 4) Class2 As a result of this Top 4 , both the classes will have the same score. But the expected result is that Class1 has a better score, as the MLT score the documents accordingly. -- 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-6678) jdk1.9.0-ea-b72 JVM failures
[
https://issues.apache.org/jira/browse/LUCENE-6678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-6678:
Attachment: hs_err_pid7608.log
{code}
[junit4] # V [libjvm.so+0x48651f] ConcurrentMark::completeCleanup()+0x9f
{code}
jdk1.9.0-ea-b72 JVM failures
Key: LUCENE-6678
URL: https://issues.apache.org/jira/browse/LUCENE-6678
Project: Lucene - Core
Issue Type: Task
Reporter: Dawid Weiss
Priority: Trivial
Attachments: hs_err_pid7402.log, hs_err_pid7407.log,
hs_err_pid7408.log, hs_err_pid7608.log
A placeholder for JDK1.9.0-ea-b72 failures.
Linked issues:
[8129961 : SIGSEGV when copying to survivor space]
https://bugs.openjdk.java.net/browse/JDK-8129961
--
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-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13711 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13711/ Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Error from server at https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1: ClusterState says we are the leader (https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1), but locally we don't think so. Request came from null Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1: ClusterState says we are the leader (https://127.0.0.1:49092/rq_jl/source_collection_shard1_replica1), but locally we don't think so. Request came from null at __randomizedtesting.SeedInfo.seed([EA39C87A9358B705:E259BD569C569F0E]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:635) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:967) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.index(BaseCdcrDistributedZkTest.java:184) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestOps(CdcrReplicationDistributedZkTest.java:436) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at
Re: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5098 - Failure!
I'll dig ... Mike McCandless http://blog.mikemccandless.com On Sun, Aug 2, 2015 at 10:53 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5098/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.lucene.rangetree.TestRangeTree.testMultiValuedSortedSet Error Message: dir=.\temp\RangeTreeWriter2453214844782505478 still has file=.\temp\RangeTreeWriter2453214844782505478\size20382.7946562357398785588 Stack Trace: java.lang.AssertionError: dir=.\temp\RangeTreeWriter2453214844782505478 still has file=.\temp\RangeTreeWriter2453214844782505478\size20382.7946562357398785588 at __randomizedtesting.SeedInfo.seed([E796DC58347808A:75003E413103FD44]:0) at org.apache.lucene.rangetree.RangeTreeWriter.directoryIsEmpty(RangeTreeWriter.java:402) at org.apache.lucene.rangetree.RangeTreeWriter.finish(RangeTreeWriter.java:391) at org.apache.lucene.rangetree.RangeTreeDocValuesConsumer.addSortedSetField(RangeTreeDocValuesConsumer.java:144) at org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addSortedSetField(PerFieldDocValuesFormat.java:131) at org.apache.lucene.codecs.DocValuesConsumer.mergeSortedSetField(DocValuesConsumer.java:736) at org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:219) at org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:150) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:105) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4075) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3650) at org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40) at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1915) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1748) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1705) at org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:408) at org.apache.lucene.rangetree.TestRangeTree.testMultiValuedSortedSet(TestRangeTree.java:229) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at
[jira] [Commented] (SOLR-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651623#comment-14651623
]
Shalin Shekhar Mangar commented on SOLR-5882:
-
[~mkhludnev] - does a score mode specified in uppercase throw an exception?
Shouldn't that be case-insensitive?
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651533#comment-14651533
]
Mikhail Khludnev commented on SOLR-5882:
[~thelabdude] I appreciate if you can have a look.
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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-6678) jdk1.9.0-ea-b72 JVM failures
[
https://issues.apache.org/jira/browse/LUCENE-6678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651565#comment-14651565
]
Dawid Weiss commented on LUCENE-6678:
-
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13527/consoleText
This seems to be a new one.
{code}
[junit4] #
[junit4] # A fatal error has been detected by the Java Runtime Environment:
[junit4] #
[junit4] # SIGSEGV (0xb) at pc=0x7f3547f9b51f, pid=7608,
tid=139866754520832
[junit4] #
[junit4] # JRE version: Java(TM) SE Runtime Environment (9.0-b60) (build
1.9.0-ea-b60)
[junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-ea-b60 mixed
mode linux-amd64 )
[junit4] # Problematic frame:
[junit4] # V [libjvm.so+0x48651f] ConcurrentMark::completeCleanup()+0x9f
[junit4] #
[junit4] # Failed to write core dump. Core dumps have been disabled. To
enable core dumping, try ulimit -c unlimited before starting Java again
[junit4] #
[junit4] # An error report file with more information is saved as:
[junit4] #
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/test/J0/hs_err_pid7608.log
[junit4] #
[junit4] # If you would like to submit a bug report, please visit:
[junit4] # http://bugreport.java.com/bugreport/crash.jsp
[junit4] #
{code}
jdk1.9.0-ea-b72 JVM failures
Key: LUCENE-6678
URL: https://issues.apache.org/jira/browse/LUCENE-6678
Project: Lucene - Core
Issue Type: Task
Reporter: Dawid Weiss
Priority: Trivial
Attachments: hs_err_pid7402.log, hs_err_pid7407.log,
hs_err_pid7408.log
A placeholder for JDK1.9.0-ea-b72 failures.
Linked issues:
[8129961 : SIGSEGV when copying to survivor space]
https://bugs.openjdk.java.net/browse/JDK-8129961
--
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-6625) Add interceptor API for outgoing calls through HttpSolrClient
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-6625: --- Attachment: SOLR-6625-revert.patch Close to 5.3, I am feeling unsure of what else is broken. Since SOLR-7692 can use the serverside request object (SolrRequestObject) directly from SolrRequestInfo, I want to revert the SolrHttpContext and the SolrHttpClient parts from this issue. We'll still continue to have the HttpRequestInterceptor support and the tests. Here's a patch to do the same. The tests are passing for me. If, at a later point, we need client side request object (SolrRequest), we can bring back these changes with more tests. Right now, that seems not necessary. Add interceptor API for outgoing calls through HttpSolrClient - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-revert.patch, SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- 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-6625) Add interceptor API for outgoing calls through HttpSolrClient
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651961#comment-14651961 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 8/3/15 3:09 PM: Close to 5.3, I am feeling unsure of what else is broken. Since SOLR-7692 can use the serverside request object (SolrRequestObject) directly from SolrRequestInfo, I want to revert the SolrHttpContext and the SolrHttpClient parts from this issue. We'll still continue to have the HttpRequestInterceptor support and the tests. Here's a patch to do the same (SOLR-6625-revert.patch). The tests are passing for me. If, at a later point, we need client side request object (SolrRequest), we can bring back these changes with more tests. Right now, that seems not necessary. was (Author: ichattopadhyaya): Close to 5.3, I am feeling unsure of what else is broken. Since SOLR-7692 can use the serverside request object (SolrRequestObject) directly from SolrRequestInfo, I want to revert the SolrHttpContext and the SolrHttpClient parts from this issue. We'll still continue to have the HttpRequestInterceptor support and the tests. Here's a patch to do the same. The tests are passing for me. If, at a later point, we need client side request object (SolrRequest), we can bring back these changes with more tests. Right now, that seems not necessary. Add interceptor API for outgoing calls through HttpSolrClient - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-revert.patch, SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- 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-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651964#comment-14651964
]
Mikhail Khludnev commented on SOLR-5882:
lowercase works. and it's up to user to leave the first letter Capital like in
enum's javadoc
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14651973#comment-14651973
]
Shalin Shekhar Mangar commented on SOLR-5882:
-
Okay, cool. +1 to commit!
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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-6712) GeoPointField should cut over to DocValues for boundary filtering
[ https://issues.apache.org/jira/browse/LUCENE-6712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6712: --- Attachment: LUCENE-6712.patch Updated patch includes the following: * added GeoPointTermQueryConstantScoreWrapper accidentally left out of last patch (forgot to add the file) * reduces precision_step to 9 to further reduce range recursion and index size * removed some duplicate diffs from LUCENE-6704 Due Diligence Benchmarks (on 60M point test data): index time: 454.891 ms from 633.196 ms (*28% performance gain*) index size: 3.9G from 4.7G (*17% reduction*) search time: 0.018 ms/query from 0.028 ms/query (*28% performance gain*) GeoPointField should cut over to DocValues for boundary filtering - Key: LUCENE-6712 URL: https://issues.apache.org/jira/browse/LUCENE-6712 Project: Lucene - Core Issue Type: Improvement Reporter: Nicholas Knize Attachments: LUCENE-6712.patch, LUCENE-6712.patch Currently GeoPointField queries only use the Terms Dictionary for ranges that fall within and on the boundary of the query shape. For boundary ranges the full precision terms are iterated, for within ranges the postings list is used. Instead of iterating full precision terms for boundary ranges, this enhancement cuts over to DocValues for post-filtering boundary terms. This allows us to increase precisionStep for GeoPointField thereby reducing the number of terms and the size of the index. This enhancement should also provide a boost in query performance since visiting more docs and fewer terms should be more efficient than visiting fewer docs and more terms. -- 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-5882) Introduce score local parameter for {!parent} query parser
[
https://issues.apache.org/jira/browse/SOLR-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652070#comment-14652070
]
Yonik Seeley commented on SOLR-5882:
bq. Okay, I don't have a serious objection to this but I just find it weird
to require case-sensitivity for such parameter names. Perhaps we can use
lowercase only?
bq. lowercase works. and it's up to user to leave the first letter Capital like
in enum's javadoc
I agree with Shalin, and I don't think the enum value is really relevant
(again, interface vs implementation... plus someone could always change the
enum).
So when this is documented in the ref guide, let's use lowecase.
Introduce score local parameter for {!parent} query parser
--
Key: SOLR-5882
URL: https://issues.apache.org/jira/browse/SOLR-5882
Project: Solr
Issue Type: New Feature
Affects Versions: 4.8
Reporter: Andrey Kudryavtsev
Assignee: Mikhail Khludnev
Fix For: 5.3
Attachments: SOLR-5882.patch, SOLR-5882.patch
I propose to have ability to configure scoring mode by local parameter
Syntax for parent queries can be like:
{code:borderStyle=solid}
{!parent which=type:parent score=None|Avg|Max|Total|Min}...
loweracase is also accepted
{code}
Child query enables scoring by default.
--
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-6706) Support Payload scoring for all SpanQueries
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652084#comment-14652084 ] Alan Woodward commented on LUCENE-6706: --- Bah, sorry Steve, will fix. Support Payload scoring for all SpanQueries --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Fix For: 5.3 Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-6417) Upgrade ANTLR to version 4.5
[ https://issues.apache.org/jira/browse/LUCENE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Conradson updated LUCENE-6417: --- Attachment: LUCENE-6471.patch Attached an updated patch. Upgrade ANTLR to version 4.5 Key: LUCENE-6417 URL: https://issues.apache.org/jira/browse/LUCENE-6417 Project: Lucene - Core Issue Type: Improvement Reporter: Jack Conradson Attachments: LUCENE-6471.patch, LUCENE-6471.patch I would like to upgrade ANTLR from 3.5 to 4.5. This version adds several features that will improve the existing grammars. The main improvement would be the allowance of left-hand recursion in grammar rules which will reduce the number of rules significantly for expressions. This change will require some code refactoring to the existing expressions 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
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5101 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5101/
Java: 32bit/jdk1.8.0_51 -client -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 5148 lines...]
[javac] Compiling 224 source files to
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\queryparser\classes\java
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\xml\builders\BoostingTermBuilder.java:5:
error: cannot find symbol
[javac] import org.apache.lucene.search.payloads.PayloadTermQuery;
[javac] ^
[javac] symbol: class PayloadTermQuery
[javac] location: package org.apache.lucene.search.payloads
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\xml\builders\BoostingTermBuilder.java:29:
error: reference not found
[javac] * Builder for {@link PayloadTermQuery}
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\classic\QueryParserTokenManager.java:493:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\classic\QueryParserTokenManager.java:687:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\classic\QueryParserTokenManager.java:860:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\flexible\standard\config\NumericConfig.java:32:
warning: [overrides] Class NumericConfig overrides equals, but neither it nor
any superclass overrides hashCode method
[javac] public class NumericConfig {
[javac]^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\flexible\standard\parser\StandardSyntaxParserTokenManager.java:375:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\flexible\standard\parser\StandardSyntaxParserTokenManager.java:495:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\flexible\standard\parser\StandardSyntaxParserTokenManager.java:668:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\surround\parser\QueryParserTokenManager.java:348:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\surround\parser\QueryParserTokenManager.java:468:
warning: [cast] redundant cast to int
[javac] int hiByte = (int)(curChar 8);
[javac] ^
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\surround\query\RewriteQuery.java:64:
warning: [rawtypes] found raw type: RewriteQuery
[javac] RewriteQuery other = (RewriteQuery)obj;
[javac] ^
[javac] missing type arguments for generic class RewriteQuerySQ
[javac] where SQ is a type-variable:
[javac] SQ extends SrndQuery declared in class RewriteQuery
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\surround\query\OrQuery.java:43:
warning: [rawtypes] found raw type: Iterator
[javac] Iterator sqi = getSubQueriesIterator();
[javac] ^
[javac] missing type arguments for generic class IteratorE
[javac] where E is a type-variable:
[javac] E extends Object declared in interface Iterator
[javac]
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\queryparser\src\java\org\apache\lucene\queryparser\surround\query\OrQuery.java:60:
warning: [rawtypes] found
[jira] [Commented] (LUCENE-6706) Support Payload scoring for all SpanQueries
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652103#comment-14652103 ] ASF subversion and git services commented on LUCENE-6706: - Commit 1693933 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1693933 ] LUCENE-6706: Commit from the right directory this time Support Payload scoring for all SpanQueries --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Fix For: 5.3 Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- 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-7865) lookup method implemented in BlendedInfixLookupFactory does not respect suggest.count
[
https://issues.apache.org/jira/browse/SOLR-7865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arcadius Ahouansou updated SOLR-7865:
-
Summary: lookup method implemented in BlendedInfixLookupFactory does not
respect suggest.count (was: loockup method implemented in
BlendedInfixLookupFactory does not respect suggest.count)
lookup method implemented in BlendedInfixLookupFactory does not respect
suggest.count
-
Key: SOLR-7865
URL: https://issues.apache.org/jira/browse/SOLR-7865
Project: Solr
Issue Type: Bug
Components: Suggester
Affects Versions: 5.2.1
Reporter: Arcadius Ahouansou
The following test failes in the TestBlendedInfixSuggestions.java:
This is mainly because {code}num * numFactor{code} get called multiple times.
{code}
public void testSuggestCount() {
assertQ(req(qt, URI, q, the, SuggesterParams.SUGGEST_COUNT, 1,
SuggesterParams.SUGGEST_DICT, blended_infix_suggest_linear),
//lst[@name='suggest']/lst[@name='blended_infix_suggest_linear']/lst[@name='the']/int[@name='numFound'][.='1'],
//lst[@name='suggest']/lst[@name='blended_infix_suggest_linear']/lst[@name='the']/arr[@name='suggestions']/lst[1]/str[@name='term'][.='top
of bthe/b lake'],
//lst[@name='suggest']/lst[@name='blended_infix_suggest_linear']/lst[@name='the']/arr[@name='suggestions']/lst[1]/long[@name='weight'][.='14'],
//lst[@name='suggest']/lst[@name='blended_infix_suggest_linear']/lst[@name='the']/arr[@name='suggestions']/lst[1]/str[@name='payload'][.='lake']
);
}
{code}
--
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-7866) getMaxVersionFromIndex is throwing an NPE if some segments are not current
Timothy Potter created SOLR-7866:
Summary: getMaxVersionFromIndex is throwing an NPE if some
segments are not current
Key: SOLR-7866
URL: https://issues.apache.org/jira/browse/SOLR-7866
Project: Solr
Issue Type: Bug
Reporter: Timothy Potter
Assignee: Timothy Potter
Priority: Blocker
Fix For: 5.3
Reported by user on #solr irc (via Shalin)
{code}
java.lang.NullPointerException
at
org.apache.lucene.util.NumericUtils.prefixCodedToLong(NumericUtils.java:226)
at org.apache.lucene.util.NumericUtils.getMaxLong(NumericUtils.java:582)
at
org.apache.solr.update.VersionInfo.getMaxVersionFromIndex(VersionInfo.java:234)
at
org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1580)
at
org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610)
at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:861)
at org.apache.solr.core.SolrCore.init(SolrCore.java:843)
at org.apache.solr.core.SolrCore.init(SolrCore.java:658)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:637)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:381)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:375)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
--
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: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
Thanks Adrien, I'll run the tests with 5.3 snapshot and post the results here. In case this helps, this is the hprof samples output (-Xrunhprof:cpu=samples,depth=3,file=/home/ec2-user/hprof_output.txt) for 4.10.4 and 5.2.1 in my test: Solr 4.10.4: CPU SAMPLES BEGIN (total = 243525) Fri Jul 31 22:29:06 2015 rank self accum count trace method 1 75.07% 75.07% 182812 300523 java.net.PlainSocketImpl.socketAccept 2 4.27% 79.34% 10408 301576 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.decodeMetaData 3 4.15% 83.49% 10108 301585 org.apache.lucene.index.FilteredTermsEnum.docs 4 3.46% 86.95%8419 301582 org.apache.lucene.index.FilteredTermsEnum.next 5 2.49% 89.44%6070 301573 java.net.SocketInputStream.socketRead0 6 1.99% 91.43%4848 301599 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 7 1.98% 93.42%4824 301583 org.apache.lucene.search.MultiTermQueryWrapperFilter.getDocIdSet 8 1.57% 94.99%3824 301589 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 9 1.44% 96.42%3504 301594 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.refillDocs 10 1.09% 97.51%2655 301581 java.nio.Bits.copyToArray 11 0.98% 98.50%2388 301598 org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsEnum.nextDoc 12 0.62% 99.12%1522 301600 org.apache.lucene.store.DataInput.readVInt 13 0.21% 99.33% 500 301612 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.docs 14 0.07% 99.39% 167 301601 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 15 0.06% 99.45% 139 301619 java.lang.System.identityHashCode 16 0.05% 99.50% 114 301632 org.apache.lucene.codecs.lucene41.ForUtil.readBlock 17 0.04% 99.54% 92 300708 java.util.zip.Inflater.inflateBytes 18 0.03% 99.57% 76 301624 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.loadNextFloorBlock 19 0.03% 99.59% 68 300613 java.lang.ClassLoader.defineClass1 20 0.03% 99.62% 68 301615 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 21 0.03% 99.65% 62 301635 org.apache.solr.search.SolrIndexSearcher.getDocSetNC 22 0.02% 99.66% 41 301664 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 23 0.01% 99.68% 31 301629 org.apache.lucene.util.FixedBitSet.init CPU SAMPLES END Solr 5.2.1: CPU SAMPLES BEGIN (total = 235415) Fri Jul 31 22:42:06 2015 rank self accum count trace method 1 51.38% 51.38% 120954 301291 sun.nio.ch.EPollArrayWrapper.epollWait 2 25.69% 77.07% 60477 301292 sun.nio.ch.ServerSocketChannelImpl.accept0 3 10.59% 87.66% 24923 301369 org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.next 4 2.20% 89.86%5182 301414 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.postings 5 2.01% 91.87%4742 301384 org.apache.lucene.index.FilterLeafReader$FilterTermsEnum.postings 6 1.25% 93.12%2944 301434 java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss 7 1.11% 94.23%2612 301367 org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite 8 0.94% 95.17%2204 301390 org.apache.lucene.util.BitSet.or 9 0.93% 96.10%2190 301383 java.nio.Bits.copyToArray 10 0.78% 96.87%1825 301449 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.refillDocs 11 0.73% 97.60%1717 301378 org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll 12 0.73% 98.33%1715 301374 org.apache.lucene.util.BitSet.or 13 0.33% 98.66% 787 301387 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 14 0.16% 98.82% 374 301426 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 15 0.10% 98.93% 245 301382 org.apache.lucene.util.BitSet.or 16 0.09% 99.02% 219 301381 org.apache.lucene.codecs.blocktree.SegmentTermsEnumFrame.next 17 0.09% 99.11% 207 301370 org.apache.lucene.util.BitSet.or 18 0.06% 99.17% 153 301416 org.apache.lucene.util.BitSet.or 19 0.06% 99.24% 151 301427 org.apache.lucene.util.BitSet.or 20 0.06% 99.30% 151 301441 org.apache.lucene.store.DataInput.readVInt 21 0.06% 99.36% 147 301389 java.lang.System.identityHashCode 22 0.06% 99.42% 140 301375 org.apache.lucene.codecs.blocktree.SegmentTermsEnum.next 23 0.04% 99.47% 104 301425 org.apache.lucene.util.BitSet.or 24 0.03% 99.50% 76 301423 org.apache.lucene.codecs.lucene50.Lucene50PostingsReader$BlockDocsEnum.nextDoc 25 0.03% 99.53% 74 301454 org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite 26 0.03% 99.56% 65 301432 org.apache.lucene.util.BitDocIdSet$Builder.or 27 0.02% 99.58% 53 301456 org.apache.lucene.util.FixedBitSet.or 28 0.02% 99.60% 52 300077 java.lang.ClassLoader.defineClass1 29 0.02% 99.63% 50 301464 org.apache.lucene.codecs.lucene50.ForUtil.readBlock 30 0.02% 99.64% 39 301438
[jira] [Commented] (LUCENE-6711) Instead of docCount(), maxDoc() is used for numberOfDocuments in SimilarityBase
[
https://issues.apache.org/jira/browse/LUCENE-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652160#comment-14652160
]
Hoss Man commented on LUCENE-6711:
--
bq. I also think its best to just make the change for trunk and not do it in a
minor version.
+1
This is the sort of behavior change that should be noted in MIGRATE.txt --
Ahmet: could you take a stab at adding the necessary text in your patch?
Instead of docCount(), maxDoc() is used for numberOfDocuments in
SimilarityBase
---
Key: LUCENE-6711
URL: https://issues.apache.org/jira/browse/LUCENE-6711
Project: Lucene - Core
Issue Type: Bug
Components: core/search
Reporter: Ahmet Arslan
Priority: Minor
Fix For: Trunk
Attachments: LUCENE-6711.patch, LUCENE-6711.patch, LUCENE-6711.patch
{{SimilarityBase.java}} has the following line :
{code}
long numberOfDocuments = collectionStats.maxDoc();
{code}
It seems like {{collectionStats.docCount()}}, which returns the total number
of documents that have at least one term for this field, is more appropriate
statistics here.
--
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-Tests-5.x-Java7 - Build # 3390 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3390/ 1 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: expected:0 but was:1 Stack Trace: java.lang.AssertionError: expected:0 but was:1 at __randomizedtesting.SeedInfo.seed([2B6CE069A5DB5A50:A338DFB30B2737A8]: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.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Updated] (SOLR-7799) LukeRequestHandler too slow when there are many fields
[ https://issues.apache.org/jira/browse/SOLR-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-7799: --- Fix Version/s: Trunk LukeRequestHandler too slow when there are many fields -- Key: SOLR-7799 URL: https://issues.apache.org/jira/browse/SOLR-7799 Project: Solr Issue Type: Bug Affects Versions: 5.2 Reporter: Erik Hatcher Assignee: Erik Hatcher Fix For: 5.3, Trunk Attachments: SOLR-7799.patch /admin/luke responds very slowly when there are many fields in the index. The issue is with getFirstLiveDoc() spinning its wheels a lot to get the index flags. -- 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-7860) Standardize use of HttpSolrClients in Solr
[
https://issues.apache.org/jira/browse/SOLR-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-7860:
---
Attachment: SOLR-7860.patch
First cut at removing so many httpclients lying around. Removing the SDF's
httpclient and using the update shard handler's httpclient.
Standardize use of HttpSolrClients in Solr
--
Key: SOLR-7860
URL: https://issues.apache.org/jira/browse/SOLR-7860
Project: Solr
Issue Type: Improvement
Reporter: Ramkumar Aiyengar
Priority: Minor
Attachments: SOLR-7860.patch
{{HttpShardHandlerFactory}} and {{UpdateShardHandler}} already provide two
places where one can get {{HttpSolrClient}}s with timeouts set up properly
etc., but there are lots of miscellaneous places which instantiate their own,
with hardcoded timeouts. These are just waiting for some environment to
realize the timeouts are not suitable, and not configurable as well. We
should standardize this (anyone knows why there two to begin with?), ideally
this hardcoding shouldn't exist at all..
--
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
