[jira] [Created] (LUCENE-4633) DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader
Shai Erera created LUCENE-4633: -- Summary: DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader Key: LUCENE-4633 URL: https://issues.apache.org/jira/browse/LUCENE-4633 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.0 Reporter: Shai Erera Assignee: Shai Erera Fix For: 4.1, 5.0 While migrating code to Lucene 4.0 I tripped it. If you call replaceTaxonomy() with e.g. a taxonomy index that contains category "a", and then you try to add category "a" to the new taxonomy, it receives a new ordinal! The reason is that replaceTaxo doesn't refresh the internal IndexReader, but does clear the cache (as it should). This causes the next addCategory to not find category "a" in the cache, and not in the reader instance at hand. Simple fix, I'll attach a patch with it and a test exposing the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4633) DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader
[ https://issues.apache.org/jira/browse/LUCENE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-4633: --- Component/s: modules/facet > DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader > - > > Key: LUCENE-4633 > URL: https://issues.apache.org/jira/browse/LUCENE-4633 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Affects Versions: 4.0 >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4633.patch > > > While migrating code to Lucene 4.0 I tripped it. If you call > replaceTaxonomy() with e.g. a taxonomy index that contains category "a", and > then you try to add category "a" to the new taxonomy, it receives a new > ordinal! > The reason is that replaceTaxo doesn't refresh the internal IndexReader, but > does clear the cache (as it should). This causes the next addCategory to not > find category "a" in the cache, and not in the reader instance at hand. > Simple fix, I'll attach a patch with it and a test exposing the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4633) DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader
[ https://issues.apache.org/jira/browse/LUCENE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-4633: --- Attachment: LUCENE-4633.patch Patch with fix and test (added to TestDirTaxoWriter.testReplaceTaxo). I plan to commit this shortly. > DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader > - > > Key: LUCENE-4633 > URL: https://issues.apache.org/jira/browse/LUCENE-4633 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Affects Versions: 4.0 >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4633.patch > > > While migrating code to Lucene 4.0 I tripped it. If you call > replaceTaxonomy() with e.g. a taxonomy index that contains category "a", and > then you try to add category "a" to the new taxonomy, it receives a new > ordinal! > The reason is that replaceTaxo doesn't refresh the internal IndexReader, but > does clear the cache (as it should). This causes the next addCategory to not > find category "a" in the cache, and not in the reader instance at hand. > Simple fix, I'll attach a patch with it and a test exposing the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4633) DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader
[ https://issues.apache.org/jira/browse/LUCENE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533324#comment-13533324 ] Gilad Barkai commented on LUCENE-4633: -- +1 patch looks good. > DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader > - > > Key: LUCENE-4633 > URL: https://issues.apache.org/jira/browse/LUCENE-4633 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Affects Versions: 4.0 >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4633.patch > > > While migrating code to Lucene 4.0 I tripped it. If you call > replaceTaxonomy() with e.g. a taxonomy index that contains category "a", and > then you try to add category "a" to the new taxonomy, it receives a new > ordinal! > The reason is that replaceTaxo doesn't refresh the internal IndexReader, but > does clear the cache (as it should). This causes the next addCategory to not > find category "a" in the cache, and not in the reader instance at hand. > Simple fix, I'll attach a patch with it and a test exposing the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4633) DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader
[ https://issues.apache.org/jira/browse/LUCENE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533325#comment-13533325 ] Commit Tag Bot commented on LUCENE-4633: [trunk commit] Shai Erera http://svn.apache.org/viewvc?view=revision&revision=1422495 LUCENE-4633: DirectoryTaxonomyWriter.replaceTaxonomy should refresh its reader > DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader > - > > Key: LUCENE-4633 > URL: https://issues.apache.org/jira/browse/LUCENE-4633 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Affects Versions: 4.0 >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4633.patch > > > While migrating code to Lucene 4.0 I tripped it. If you call > replaceTaxonomy() with e.g. a taxonomy index that contains category "a", and > then you try to add category "a" to the new taxonomy, it receives a new > ordinal! > The reason is that replaceTaxo doesn't refresh the internal IndexReader, but > does clear the cache (as it should). This causes the next addCategory to not > find category "a" in the cache, and not in the reader instance at hand. > Simple fix, I'll attach a patch with it and a test exposing the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4633) DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader
[ https://issues.apache.org/jira/browse/LUCENE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-4633. Resolution: Fixed Committed to 4x and trunk > DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader > - > > Key: LUCENE-4633 > URL: https://issues.apache.org/jira/browse/LUCENE-4633 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Affects Versions: 4.0 >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4633.patch > > > While migrating code to Lucene 4.0 I tripped it. If you call > replaceTaxonomy() with e.g. a taxonomy index that contains category "a", and > then you try to add category "a" to the new taxonomy, it receives a new > ordinal! > The reason is that replaceTaxo doesn't refresh the internal IndexReader, but > does clear the cache (as it should). This causes the next addCategory to not > find category "a" in the cache, and not in the reader instance at hand. > Simple fix, I'll attach a patch with it and a test exposing the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4633) DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader
[ https://issues.apache.org/jira/browse/LUCENE-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533329#comment-13533329 ] Commit Tag Bot commented on LUCENE-4633: [branch_4x commit] Shai Erera http://svn.apache.org/viewvc?view=revision&revision=1422497 LUCENE-4633: DirectoryTaxonomyWriter.replaceTaxonomy should refresh its reader > DirectoryTaxonomyWriter.replaceTaxonomy should refresh the reader > - > > Key: LUCENE-4633 > URL: https://issues.apache.org/jira/browse/LUCENE-4633 > Project: Lucene - Core > Issue Type: Bug > Components: modules/facet >Affects Versions: 4.0 >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4633.patch > > > While migrating code to Lucene 4.0 I tripped it. If you call > replaceTaxonomy() with e.g. a taxonomy index that contains category "a", and > then you try to add category "a" to the new taxonomy, it receives a new > ordinal! > The reason is that replaceTaxo doesn't refresh the internal IndexReader, but > does clear the cache (as it should). This causes the next addCategory to not > find category "a" in the cache, and not in the reader instance at hand. > Simple fix, I'll attach a patch with it and a test exposing the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4258) Incremental Field Updates through Stacked Segments
[ https://issues.apache.org/jira/browse/LUCENE-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533359#comment-13533359 ] Sivan Yogev commented on LUCENE-4258: - Let me start with the last question. bq. Are stored fields now sparse? Meaning if I have a segment w/ many docs, and I update stored fields on one doc, in that tiny stacked segments will the stored fields files also be tiny? In such case you will get the equivalent of a segment with multiple docs with only one of them containing stored fields. I assume the impls of stored fields handle these cases well and you will indeed get tiny stored fields. Regarding the API - I made some cleanup, and removed also Operation.ADD_DOCUMENT. Now there is only one way to perform each operation, and updateFields only allows you to add or replace fields given a term. bq. This means you cannot reuse fields, you have to be careful with pre-tokenized fields (can't reuse the TokenStream), etc. This is referred in the Javadoc of updateFields, let me know if there's a better way to address it. As for the heavier questions. NRT support should be considered separately, but the guideline I followed was to keep things as closely as possible to the way deletions are handled. Therefore, we need to add to SegmentReader a field named liveUpdates - an equivalent to liveDocs. I already put a TODO for this (SegmentReader line 131), implementing it won't be simple... The performance tradeoff you are rightfully concerned about should be handled through merging. Once you merge an updated segment all updates are "cleaned", and the new segment has no performance issues. Apps that perform updates should make sure (through MergePolicy) to avoid reader-side updates as much as possible. > Incremental Field Updates through Stacked Segments > -- > > Key: LUCENE-4258 > URL: https://issues.apache.org/jira/browse/LUCENE-4258 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Sivan Yogev > Attachments: IncrementalFieldUpdates.odp, > LUCENE-4258-API-changes.patch, LUCENE-4258.r1410593.patch, > LUCENE-4258.r1412262.patch, LUCENE-4258.r1416438.patch, > LUCENE-4258.r1416617.patch > > Original Estimate: 2,520h > Remaining Estimate: 2,520h > > Shai and I would like to start working on the proposal to Incremental Field > Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4258) Incremental Field Updates through Stacked Segments
[ https://issues.apache.org/jira/browse/LUCENE-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-4258: Attachment: LUCENE-4258.r1422495.patch Patch with some additional bug fixes and more elaborate tests, all working. Ready to commit? > Incremental Field Updates through Stacked Segments > -- > > Key: LUCENE-4258 > URL: https://issues.apache.org/jira/browse/LUCENE-4258 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Sivan Yogev > Attachments: IncrementalFieldUpdates.odp, > LUCENE-4258-API-changes.patch, LUCENE-4258.r1410593.patch, > LUCENE-4258.r1412262.patch, LUCENE-4258.r1416438.patch, > LUCENE-4258.r1416617.patch, LUCENE-4258.r1422495.patch > > Original Estimate: 2,520h > Remaining Estimate: 2,520h > > Shai and I would like to start working on the proposal to Incremental Field > Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4112) Dataimporting with SolrCloud Fails
[ https://issues.apache.org/jira/browse/SOLR-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4112: - Priority: Blocker (was: Major) Making this a blocker so we are sure to deal with it before 4.1 is cut. I won't have time to deal until next week and don't want to forget it. > Dataimporting with SolrCloud Fails > -- > > Key: SOLR-4112 > URL: https://issues.apache.org/jira/browse/SOLR-4112 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0 >Reporter: Deniz Durmus >Assignee: James Dyer >Priority: Blocker > Fix For: 4.1, 5.0 > > Attachments: SOLR-4112.patch > > > While trying to import data from db on cloud, it shows this in logs: > SEVERE: Full Import > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable > to PropertyWriter implementation:ZKPropertiesWriter > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:336) > > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:418) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) > Caused by: org.apache.solr.common.cloud.ZooKeeperException: > ZkSolrResourceLoader does not support getConfigDir() - likely, what you are > trying to do is not supported in ZooKeeper mode > at > org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:100) > > at > org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:91) > > at > org.apache.solr.handler.dataimport.ZKPropertiesWriter.init(ZKPropertiesWriter.java:45) > > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:334) > > ... 3 more > Exception in thread "Thread-306" java.lang.NullPointerException > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:427) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #185: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/185/ 1 tests failed. FAILED: org.apache.solr.cloud.SyncSliceTest.testDistribSearch Error Message: Shard still reported as live in zk - 0 jetty Stack Trace: java.lang.AssertionError: Shard still reported as live in zk - 0 jetty at __randomizedtesting.SeedInfo.seed([34265A506D6C48B:82A4EBBD7189A4B7]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitToSeeNotLive(AbstractFullDistribZkTestBase.java:1239) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitToSeeNotLive(AbstractFullDistribZkTestBase.java:1224) at org.apache.solr.cloud.SyncSliceTest.waitToSeeDownInClusterState(SyncSliceTest.java:259) at org.apache.solr.cloud.SyncSliceTest.doTest(SyncSliceTest.java:163) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:793) 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:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) 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:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.eval
[jira] [Updated] (SOLR-4201) Combination of a core being swappable and loading on startup doesn't actually load on startup
[ https://issues.apache.org/jira/browse/SOLR-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4201: - Attachment: SOLR-4201.patch Shawn: The change I suggested isn't quite correct, the swappable core will go in the un-swappable list, but at least it'll be loaded at startup. The attached patch (against trunk/5x) is the correct fix, I changed the tests to catch these conditions. I'll be checking this in and merging into 4x this morning. Thanks for reporting! > Combination of a core being swappable and loading on startup doesn't actually > load on startup > - > > Key: SOLR-4201 > URL: https://issues.apache.org/jira/browse/SOLR-4201 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-4201.patch, SOLR-4201.patch > > > See Shawn's comment on SOLR-1028. Problem is this line (611 currently) in > CoreContainer.xml (4x) > if (!p.isSwappable() && p.isLoadOnStartup()) > Should be || instead I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4085) Commit-free ExternalFileField
[ https://issues.apache.org/jira/browse/SOLR-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-4085: --- Attachment: SOLR-4085.patch by following [~ysee...@gmail.com] advice I solved atomicity problem by using SolrRequestInfo <>: have a look to new testSearchSortAtomicityVsReload and testSearchAtomicityVsReload I moved TestExternalFileFieldReload to schema-eff.xml, unfortunately I needed to amend its' present usage ExternalFileFieldSortTest The evil is in FileFloatSource.Cache.resetAllReaders(Objectkey) right now it warns when detects the race: # one thread are loading the file version 333 lazily # new file version 334 is created (333 is still being loading) # reload request submitted, it places _loading placeholder_ in cache and responses Ok. (333 is still being loading) # 333 load is over, it substitutes palceholder which was purposed for picking 334 # new search see 333 not 334 I don't think it's a blocker, for someone. Surprisingly right after clicking Attach, I realized that it's possible to address this race. Obviously efforts will payed for testing rather than impl itself. Stay tuned. Looking forward for your feedback. > Commit-free ExternalFileField > - > > Key: SOLR-4085 > URL: https://issues.apache.org/jira/browse/SOLR-4085 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 4.1 >Reporter: Mikhail Khludnev > Labels: externalfilefield > Attachments: SOLR-4085.patch, SOLR-4085.patch > > > Let's reload ExternalFileFields without commit! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4201) Combination of a core being swappable and loading on startup doesn't actually load on startup
[ https://issues.apache.org/jira/browse/SOLR-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533402#comment-13533402 ] Commit Tag Bot commented on SOLR-4201: -- [trunk commit] Erick Erickson http://svn.apache.org/viewvc?view=revision&revision=1422585 Fix for SOLR-4201 (swappable cores should respect loadOnStartup) > Combination of a core being swappable and loading on startup doesn't actually > load on startup > - > > Key: SOLR-4201 > URL: https://issues.apache.org/jira/browse/SOLR-4201 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-4201.patch, SOLR-4201.patch > > > See Shawn's comment on SOLR-1028. Problem is this line (611 currently) in > CoreContainer.xml (4x) > if (!p.isSwappable() && p.isLoadOnStartup()) > Should be || instead I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-4124) You should be able to set the update log directory with the CoreAdmin API the same way as the data directory.
[ https://issues.apache.org/jira/browse/SOLR-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reopened SOLR-4124: --- This needs persistence support. > You should be able to set the update log directory with the CoreAdmin API the > same way as the data directory. > - > > Key: SOLR-4124 > URL: https://issues.apache.org/jira/browse/SOLR-4124 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4124.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4258) Incremental Field Updates through Stacked Segments
[ https://issues.apache.org/jira/browse/LUCENE-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533410#comment-13533410 ] Sivan Yogev commented on LUCENE-4258: - Some existing tests fail with the latest patch, working on fixes. > Incremental Field Updates through Stacked Segments > -- > > Key: LUCENE-4258 > URL: https://issues.apache.org/jira/browse/LUCENE-4258 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Sivan Yogev > Attachments: IncrementalFieldUpdates.odp, > LUCENE-4258-API-changes.patch, LUCENE-4258.r1410593.patch, > LUCENE-4258.r1412262.patch, LUCENE-4258.r1416438.patch, > LUCENE-4258.r1416617.patch, LUCENE-4258.r1422495.patch > > Original Estimate: 2,520h > Remaining Estimate: 2,520h > > Shai and I would like to start working on the proposal to Incremental Field > Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #709: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/709/ 2 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch Error Message: Shard still reported as live in zk - 0 jetty Stack Trace: java.lang.AssertionError: Shard still reported as live in zk - 0 jetty at __randomizedtesting.SeedInfo.seed([C84B3DD841EBB3FB:49ADB3C036B4D3C7]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitToSeeNotLive(AbstractFullDistribZkTestBase.java:1239) at org.apache.solr.cloud.BasicDistributedZk2Test.brindDownShardIndexSomeDocsAndRecover(BasicDistributedZk2Test.java:217) at org.apache.solr.cloud.BasicDistributedZk2Test.doTest(BasicDistributedZk2Test.java:92) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:793) 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:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) 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:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) 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 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotse
[jira] [Commented] (SOLR-4157) Add more conventional search functionality to the Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533429#comment-13533429 ] Erick Erickson commented on SOLR-4157: -- OK, I finally got off the road and had a chance to look. Comments: 1> Looks like a really good idea. 2> It'd be really cool to have JSON and XML be formatted in the pane by default, they're ugly as it stands. But only if it's really, really easy. 3> Not quite sure what you mean by using Velocity, this appears to display the fields you ask for as it stands. 4> Long lists overrun the pane in Chrome, assuming it's something you just haven't gotten to yet. 5> I agree that the list of options are kind of intimidating, but I'm not all that concerned with simplifying it. In fact I kind of like the fact that the options are there inviting people to play with them. Let's send them to the browse handler for a more real-life "user experience", I think leaving this for mostly expert/debugging is fine. 6> What do you think should be done with debug and facet and highlight info? I'm thinking just a continuation of the pane, really just prettifying the output. You code, I'll commit ... Erick > Add more conventional search functionality to the Admin UI > -- > > Key: SOLR-4157 > URL: https://issues.apache.org/jira/browse/SOLR-4157 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Upayavira >Priority: Minor > Attachments: SOLR-4157.patch > > > The admin UI has a 'query' pane which allows searching the index. However, > this is currently an 'expert' level feature, as you must specify exact > request parameters and interpret output XML or JSON. > I suggest we add simple versions of each. A simple query pane would give a > more conventional search interface for running queries. A simple results pane > would give HTML formatted results with features to nicely display > hightlighting, explains, etc. > To give an idea of what this might look like, I've attached a rudimentary > patch that gives an HTML option for wt which formats the query results as > (somewhat minimal) HTML. > The challenge will be in producing a search interface that is schema > agnostic, as to be really useful, it should work with any index, and not just > with the fields in the default schema (perhaps Erik Hatcher is right, this > should be backed by the velocityResponseWriter). > Thoughts welcome. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4201) Combination of a core being swappable and loading on startup doesn't actually load on startup
[ https://issues.apache.org/jira/browse/SOLR-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-4201. -- Resolution: Fixed Fix Version/s: 5.0 4.1 trunk - r: 1422585 4x- r: 1422632 Thanks Shawn! > Combination of a core being swappable and loading on startup doesn't actually > load on startup > - > > Key: SOLR-4201 > URL: https://issues.apache.org/jira/browse/SOLR-4201 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4201.patch, SOLR-4201.patch > > > See Shawn's comment on SOLR-1028. Problem is this line (611 currently) in > CoreContainer.xml (4x) > if (!p.isSwappable() && p.isLoadOnStartup()) > Should be || instead I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533437#comment-13533437 ] Commit Tag Bot commented on SOLR-4203: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1422609 SOLR-4203: tweak how delete is handled so this test passes on windows > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4201) Combination of a core being swappable and loading on startup doesn't actually load on startup
[ https://issues.apache.org/jira/browse/SOLR-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533436#comment-13533436 ] Commit Tag Bot commented on SOLR-4201: -- [branch_4x commit] Erick Erickson http://svn.apache.org/viewvc?view=revision&revision=1422632 Merge from trunk for SOLR-4201 (Combination of a core being swappable and loading on startup doesn't actually load on startup) > Combination of a core being swappable and loading on startup doesn't actually > load on startup > - > > Key: SOLR-4201 > URL: https://issues.apache.org/jira/browse/SOLR-4201 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4201.patch, SOLR-4201.patch > > > See Shawn's comment on SOLR-1028. Problem is this line (611 currently) in > CoreContainer.xml (4x) > if (!p.isSwappable() && p.isLoadOnStartup()) > Should be || instead I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533438#comment-13533438 ] Commit Tag Bot commented on SOLR-4203: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1422608 SOLR-4203: tweak how delete is handled so this test passes on windows > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533452#comment-13533452 ] Mark Miller commented on SOLR-4203: --- So this will pass on Windows now, but I think something is still off. When I close an UpdateLog I can't seem to delete all it's files on Windows - so it appears perhaps something is not getting closed...that's my guess anyway, I still have to investigate. > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533463#comment-13533463
]
Shawn Heisey commented on SOLR-4143:
Further research has shown that the qt.path parameter has bleed-through
problems with any kind of distributed search. This request, to a shard core
(one with data that has no shards parameter), works:
/solr/inclive/select?q=a&qt.path=/misc/not/valid
The same request, when sent to a core with the shards parameter, fails.
/solr/ncmain/select?q=a&qt.path=/misc/not/valid
The error message in all sections of shards.info is:
{noformat}
org.apache.solr.common.SolrException: Server at
http://bigindy5.REDACTED.com:8982/solr/inclive returned non ok status:404,
message:Not Found
{noformat}
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533465#comment-13533465
]
Shawn Heisey commented on SOLR-4143:
I did look into the idea of making it so that when an alternate parameter is
used to say "just change the path, don't include the parameter." The problem
with that is that at the point where I'd have to remove the QT parameter from
the request, the parameters are in a SolrParams instead of a
ModifiableSolrParams, so I can't remove a parameter. It would probably be
pretty easy to change that, but I figure there might be a particular reason the
read-only object was chosen. Can anyone comment on that?
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[
https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533472#comment-13533472
]
Yonik Seeley commented on SOLR-4203:
Trying to wrap my head around non-persistent Directories...
{code}
initLog();
+if (!core.getDirectoryFactory().isPersistent()) {
+ try {
+clearLog();
+ } catch (IOException e) {
+throw new RuntimeException(e);
+ }
+}
{code}
Doing it this way seems tricky... The UpdateLog wasn't originally really
written with rebooting in mind, and I don't know what traps might be there (and
this may be the cause of tlog files that can't be removed under windows now).
Seems more straightforward to delete the directory before initializing the log.
Only tricky part there is finding out where the directory is.
Perhaps this clearing logic should just be done directly in the UpdateLog.init()
> An ephemeral directory implementation should cause the transaction log to be
> ignored on startup.
>
>
> Key: SOLR-4203
> URL: https://issues.apache.org/jira/browse/SOLR-4203
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4203.patch
>
>
> If you are using something like ram dir, you can restart a node and if no
> updates have come in, it will think its up to date but be empty - we should
> clear the update log in these cases on startup.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533474#comment-13533474 ] Mark Miller commented on SOLR-4203: --- bq. Seems more straightforward to delete the directory before initializing the log. Only tricky part there is finding out where the directory is. Yeah, that is actually what I was going to do first. But the getting the tlog dir was no so straightforward and that is why I went this way. This only happens on startup though, so I'm not sure why it would be a problem? It will be single threaded and before anything is being accessed. It does still seem strange to me that I cannot close the update log and delete it's data dir. That fails and we are not even to opening a new one yet. > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533474#comment-13533474 ] Mark Miller edited comment on SOLR-4203 at 12/16/12 6:59 PM: - bq. Seems more straightforward to delete the directory before initializing the log. Only tricky part there is finding out where the directory is. Yeah, that is actually what I was going to do first. But the getting the tlog dir was no so straightforward and that is why I went this way. This only happens on startup though, so I'm not sure why it would be a problem? It will be single threaded and before anything is being accessed. It does still seem strange to me that I cannot close the update log and delete it's data dir. That fails and we are not even to opening a new one yet. was (Author: markrmil...@gmail.com): bq. Seems more straightforward to delete the directory before initializing the log. Only tricky part there is finding out where the directory is. Yeah, that is actually what I was going to do first. But the getting the tlog dir was no so straightforward and that is why I went this way. This only happens on startup though, so I'm not sure why it would be a problem? It will be single threaded and before anything is being accessed. It does still seem strange to me that I cannot close the update log and delete it's data dir. That fails and we are not even to opening a new one yet. > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4461) Multiple FacetRequest with the same path creates inconsistent results
[
https://issues.apache.org/jira/browse/LUCENE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-4461.
Resolution: Fixed
Fix Version/s: 5.0
4.1
Assignee: Shai Erera
Lucene Fields: New,Patch Available (was: New)
Thanks for the fix Gilad. I did the following:
* Fixed a couple of typos.
* Updated the patch following the recent changes to FacetSearchParams (no
addRequest anymore).
* Made the test assert that the results.toString() match, rather than just
numValidDecendants.
* Added a CHANGES entry.
Committed to trunk and 4x.
> Multiple FacetRequest with the same path creates inconsistent results
> -
>
> Key: LUCENE-4461
> URL: https://issues.apache.org/jira/browse/LUCENE-4461
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Affects Versions: 3.6
>Reporter: Rodrigo Vega
>Assignee: Shai Erera
> Labels: facet, faceted-search
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4461.patch, LuceneFacetTest.java
>
>
> Multiple FacetRequest are getting merged into one creating wrong results in
> this case:
> FacetSearchParams facetSearchParams = new FacetSearchParams();
> facetSearchParams.addFacetRequest(new CountFacetRequest(new
> CategoryPath("author"), 10));
> facetSearchParams.addFacetRequest(new CountFacetRequest(new
> CategoryPath("author"), 10));
> Problem can be fixed by defining hashcode and equals in certain way that
> Lucene recognize we are talking about different requests.
> Attached test case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4461) Multiple FacetRequest with the same path creates inconsistent results
[
https://issues.apache.org/jira/browse/LUCENE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533485#comment-13533485
]
Commit Tag Bot commented on LUCENE-4461:
[branch_4x commit] Shai Erera
http://svn.apache.org/viewvc?view=revision&revision=1422671
LUCENE-4461: adding same FacetRequest more than once yielded inconsistent
results
> Multiple FacetRequest with the same path creates inconsistent results
> -
>
> Key: LUCENE-4461
> URL: https://issues.apache.org/jira/browse/LUCENE-4461
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Affects Versions: 3.6
>Reporter: Rodrigo Vega
>Assignee: Shai Erera
> Labels: facet, faceted-search
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4461.patch, LuceneFacetTest.java
>
>
> Multiple FacetRequest are getting merged into one creating wrong results in
> this case:
> FacetSearchParams facetSearchParams = new FacetSearchParams();
> facetSearchParams.addFacetRequest(new CountFacetRequest(new
> CategoryPath("author"), 10));
> facetSearchParams.addFacetRequest(new CountFacetRequest(new
> CategoryPath("author"), 10));
> Problem can be fixed by defining hashcode and equals in certain way that
> Lucene recognize we are talking about different requests.
> Attached test case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533487#comment-13533487 ] Yonik Seeley commented on SOLR-4203: TestRecovery.testCorruptLog does a deleteLogs at the end, which should fail on Windows if we had a descriptor leak through the normal path of operations. > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4461) Multiple FacetRequest with the same path creates inconsistent results
[
https://issues.apache.org/jira/browse/LUCENE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533486#comment-13533486
]
Commit Tag Bot commented on LUCENE-4461:
[trunk commit] Shai Erera
http://svn.apache.org/viewvc?view=revision&revision=1422670
LUCENE-4461: adding same FacetRequest more than once yielded inconsistent
results
> Multiple FacetRequest with the same path creates inconsistent results
> -
>
> Key: LUCENE-4461
> URL: https://issues.apache.org/jira/browse/LUCENE-4461
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Affects Versions: 3.6
>Reporter: Rodrigo Vega
>Assignee: Shai Erera
> Labels: facet, faceted-search
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4461.patch, LuceneFacetTest.java
>
>
> Multiple FacetRequest are getting merged into one creating wrong results in
> this case:
> FacetSearchParams facetSearchParams = new FacetSearchParams();
> facetSearchParams.addFacetRequest(new CountFacetRequest(new
> CategoryPath("author"), 10));
> facetSearchParams.addFacetRequest(new CountFacetRequest(new
> CategoryPath("author"), 10));
> Problem can be fixed by defining hashcode and equals in certain way that
> Lucene recognize we are talking about different requests.
> Attached test case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4204) Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments.
Mark Miller created SOLR-4204: - Summary: Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments. Key: SOLR-4204 URL: https://issues.apache.org/jira/browse/SOLR-4204 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.1, 5.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4085) Commit-free ExternalFileField
[
https://issues.apache.org/jira/browse/SOLR-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-4085:
---
Attachment: SOLR-4085.patch
added spin on race between lazy file loading and reload request. not absolutely
accurate, and efficient, but should be reliable enough. see
testSearchReloadRace. now race looks like (it's a test log)
{noformat}
oassf.FileFloatSource.getFloats Loaded external value source
external_test_make_a_pause_SOLR_4085_extf
oassf.FileFloatSource$ReloadFieldRequestHandler.handleRequestBody reloading
field test_make_a_pause_SOLR_4085_extf
oassf.FileFloatSource$Cache.resetAllReaders WARNING concurrent lazy loading
while reloading field: FileFloatSource.Key
[field=test_make_a_pause_SOLR_4085_extf .. file will loaded again
oassf.FileFloatSource.getValues WARNING concurrent reload detected. load file
again FileFloatSource.Key [field=test_make_a_pause_SOLR_4085_extf
oassf.FileFloatSource.getFloats Loaded external value source
external_test_make_a_pause_SOLR_4085_extf
{noformat}
race detection has a false positive case, which can be easily fixed. see
comment at FileFloatSource.getValues().
> Commit-free ExternalFileField
> -
>
> Key: SOLR-4085
> URL: https://issues.apache.org/jira/browse/SOLR-4085
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Affects Versions: 4.1
>Reporter: Mikhail Khludnev
> Labels: externalfilefield
> Attachments: SOLR-4085.patch, SOLR-4085.patch, SOLR-4085.patch
>
>
> Let's reload ExternalFileFields without commit!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533511#comment-13533511 ] Yonik Seeley commented on SOLR-4203: Seems like another issue is that it could introduce a race... starting the update log could start recovery, which may or may not finish before the update log is closed. > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4204) Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments.
[ https://issues.apache.org/jira/browse/SOLR-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533512#comment-13533512 ] Mark Miller commented on SOLR-4204: --- Maven builds still run the Solr tests and now that Uwe has added the switch to use socket rather than selector on freebsd with blackhole, jenkins is running Solr test in other jobs agains as well. We should improve things somehow. > Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments. > --- > > Key: SOLR-4204 > URL: https://issues.apache.org/jira/browse/SOLR-4204 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533511#comment-13533511 ] Yonik Seeley edited comment on SOLR-4203 at 12/16/12 9:12 PM: -- Seems like another issue is that it could introduce a race... starting the update log could start recovery, which may or may not finish before the update log is closed. edit: actually init() doesn't kick off recovery. But the fact remains, UpdateLog was not meant to be closed and re-inited (there is other state that probably doesn't get cleared, etc). was (Author: ysee...@gmail.com): Seems like another issue is that it could introduce a race... starting the update log could start recovery, which may or may not finish before the update log is closed. > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-4143:
---
Attachment: SOLR-4143.patch
Udpated patch. CommonParams.QT_PATHONLY is a string parameter that if set to
CommonParams.TRUE, will result in the URL path changing but all evidence of QT
and QT_PATHONLY being removed from the final parameters. There is already
precedent for the way I solved this in HttpSolrServer. This patch fixes the
problem I'm having on SOLR-4194 as well.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4194) PingRequestHandler - shards parameter inherited from search handler definition
[ https://issues.apache.org/jira/browse/SOLR-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533525#comment-13533525 ] Shawn Heisey commented on SOLR-4194: Updated patch for SOLR-4143 fixes this problem as well. > PingRequestHandler - shards parameter inherited from search handler definition > -- > > Key: SOLR-4194 > URL: https://issues.apache.org/jira/browse/SOLR-4194 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 > Environment: solr-impl4.1-SNAPSHOT 1421496 - ncindex - 2012-12-13 > 14:56:25 >Reporter: Shawn Heisey > Fix For: 4.1, 5.0 > > > Included in all my cores is a PingRequestHandler named /admin/ping, which I > use to enable/disable the server from the perspective of a load balancer > running haproxy. The handler includes a qt parameter set to /lbcheck. > I have a special core defined (I call it a broker) that includes the shards > parameter in most of its search handler definitions. This includes /select, > /lbcheck, and others. > When the /admin/ping handler is called, the query is sent to the /lbcheck > parameter as expected, which gets distributed because it includes shards. If > one of those shards happens to be down, the handler will give an error > response to the load balancer. > The problem is that the PingRequestHandler seems to inherit the shards > parameter from the search handler it is using, which causes the /admin/ping > request itself to be distributed, which is not what I want. The individual > shards are not used by the load balancer, so they always remain disabled. > This works perfectly in 3.5.0. The official 4.0.0 release has not been > tested. > Config and log data will follow in the comments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533528#comment-13533528
]
Shawn Heisey commented on SOLR-4143:
The new patch involves a number of formatting changes. I did a reformat on
eclipse, then went back and made the javadoc formats more compact than what the
reformat produced. I can see in the eclipse settings that a formatter profile
has been supplied, so I hope this meets apache guidelines.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor
Uwe Schindler created SOLR-4205:
---
Summary: Clover runs on ASF Jenkins idle dead without a test or
any thread running in main() loop waiting for file descriptor
Key: SOLR-4205
URL: https://issues.apache.org/jira/browse/SOLR-4205
Project: Solr
Issue Type: Bug
Components: Tests
Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss
I had to kill ASF Jenkins Clover builds two times after several 10 hours of
inactivity in a random Solr test. I requested a stack trace before killing the
only running JVM (clover runs with one JVM only, because clover does not like
multiple processes writing the same clover metrics file).
In both cases (4.x and trunk) the stack trace was looking identical after
sending kill -3...
https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull
(yesterday):
{noformat}
[junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org):
2012-12-16T13:01:00, stalled for 28447s at:
TestFunctionQuery.testBooleanFunctions
[junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org):
2012-12-16T13:02:00, stalled for 28507s at:
TestFunctionQuery.testBooleanFunctions
[junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org):
2012-12-16T13:03:00, stalled for 28567s at:
TestFunctionQuery.testBooleanFunctions
[junit4:junit4] JVM J0: stdout was not empty, see:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
[junit4:junit4] >>> JVM J0: stdout (verbatim)
[junit4:junit4] 2012-12-16 13:03:49
[junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed mode):
[junit4:junit4]
[junit4:junit4] "searcherExecutor-2577-thread-1" prio=5 tid=0x00085eb67000
nid=0x61c105b waiting on condition [0x70b0d000]
[junit4:junit4]java.lang.Thread.State: WAITING (parking)
[junit4:junit4] at sun.misc.Unsafe.park(Native Method)
[junit4:junit4] - parking to wait for <0x0008178c9c40> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
[junit4:junit4] at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
[junit4:junit4] at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
[junit4:junit4] at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
[junit4:junit4] at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
[junit4:junit4] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
[junit4:junit4] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[junit4:junit4] at java.lang.Thread.run(Thread.java:679)
[junit4:junit4]
[junit4:junit4] "RMI TCP Accept-0" daemon prio=5 tid=0x000840ce2800
nid=0x61c0aa2 runnable [0x79496000]
[junit4:junit4]java.lang.Thread.State: RUNNABLE
[junit4:junit4] at java.net.PlainSocketImpl.socketAccept(Native Method)
[junit4:junit4] at
java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
[junit4:junit4] at
java.net.ServerSocket.implAccept(ServerSocket.java:470)
[junit4:junit4] at java.net.ServerSocket.accept(ServerSocket.java:438)
[junit4:junit4] at
sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
[junit4:junit4] at
sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
[junit4:junit4] at java.lang.Thread.run(Thread.java:679)
[junit4:junit4]
[junit4:junit4] "RMI Scheduler(0)" daemon prio=5 tid=0x000840ce1000
nid=0x61c0969 waiting on condition [0x70f11000]
[junit4:junit4]java.lang.Thread.State: WAITING (parking)
[junit4:junit4] at sun.misc.Unsafe.park(Native Method)
[junit4:junit4] - parking to wait for <0x000814f12f88> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
[junit4:junit4] at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
[junit4:junit4] at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
[junit4:junit4] at
java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
[junit4:junit4] at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:688)
[junit4:junit4] at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:681)
[junit4:junit4] at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
[junit4:junit4] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
[junit4:junit4] at
[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-4143:
---
Attachment: SOLR-4143.patch
New patch. Minor tweaks to javadocs. One file in the patch only had
formatting changes, so I opted to not update that file. This patch is against
trunk, but will apply to branch_4x cleanly as well.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
> SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533546#comment-13533546
]
Shawn Heisey commented on SOLR-4143:
All tests in branch_4x/solr are passing. Some tests in trunk/solr are not
passing, but my putty scrollback wasn't large enough to see what went wrong.
Fixed the scrollback, running again to see if it might be related to these
changes.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
> SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4204) Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments.
[ https://issues.apache.org/jira/browse/SOLR-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4204: -- Attachment: SOLR-4204.patch Patch attached. > Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments. > --- > > Key: SOLR-4204 > URL: https://issues.apache.org/jira/browse/SOLR-4204 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4204.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533549#comment-13533549
]
Shawn Heisey commented on SOLR-4143:
The trunk test that is failing is -Dtestcase=OverseerTest
-Dtests.method=testShardAssignmentBigger, with an OOM error. Because all tests
pass on 4x, I will assume for now that this is not caused by my patch. Below
is the output at the end of the test failure:
{noformat}
[junit4:junit4] 2> NOTE: reproduce with: ant test -Dtestcase=OverseerTest
-Dtests.method=testShardAssignmentBigger -Dtests.seed=A7B9F065762AB900
-Dtests.slow=true -Dtests.locale=es_BO -Dtests.timezone=Africa/Addis_Ababa
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 5.79s J1 | OverseerTest.testShardAssignmentBigger <<<
[junit4:junit4]> Throwable #1: java.lang.RuntimeException:
java.lang.OutOfMemoryError: unable to create new native thread
[junit4:junit4]>at
__randomizedtesting.SeedInfo.seed([A7B9F065762AB900:34570E1E9C434663]:0)
[junit4:junit4]>at
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:124)
[junit4:junit4]>at
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:94)
[junit4:junit4]>at
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:85)
[junit4:junit4]>at
org.apache.solr.cloud.OverseerTest$MockZKController.(OverseerTest.java:73)
[junit4:junit4]>at
org.apache.solr.cloud.OverseerTest.testShardAssignmentBigger(OverseerTest.java:263)
[junit4:junit4]>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit4:junit4]>at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit4:junit4]>at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4:junit4]>at java.lang.reflect.Method.invoke(Method.java:601)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
[junit4:junit4]>at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
[junit4:junit4]>at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
[junit4:junit4]>at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
[junit4:junit4]>at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
[junit4:junit4]>at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4]>at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4]>at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
[junit4:junit4]>at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
[junit4:junit4]>at
org.apache.lucene.util.TestRuleS
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533559#comment-13533559
]
Mark Miller commented on SOLR-4143:
---
Yeah, it should not be related.
Looks like that test might be creating too many threads - I have not seen it
before though. We should probably file a JIRA to look into the tests thread
usage.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
> SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Christianson updated SOLR-1782: - Attachment: SOLR-1782.patch This patch is for Solr 4.0 > stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued > fields > - > > Key: SOLR-1782 > URL: https://issues.apache.org/jira/browse/SOLR-1782 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 > Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: > CHANGES.txt 906924 2010-02-05 12:43:11Z noble $) >Reporter: Gerald DeConto > Attachments: index.rar, SOLR-1782.2.patch, SOLR-1782.patch, > SOLR-1782.patch, SOLR-1782.test.patch > > > the StatsComponent assumes any field specified in the stats.facet param can > be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems > with a variety of field types, but in the case of multivalued fields it can > either cause erroneous false stats when the number of distinct values is > small, or it can cause ArrayIndexOutOfBoundsException when the number of > distinct values is greater then the number of documents. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533566#comment-13533566 ] David Christianson edited comment on SOLR-1782 at 12/16/12 11:43 PM: - I have a real need for this functionality and had been using the supplied patch on older distributions. However in more recent builds several classes changed and there was an exception added if you tried to write a stats query using a multivalued facet. So I've taken the code in the original patch and updated it for Solr 4.0, removing the exception and adding a couple of unit tests. was (Author: dchristianson): This patch is for Solr 4.0 > stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued > fields > - > > Key: SOLR-1782 > URL: https://issues.apache.org/jira/browse/SOLR-1782 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 > Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: > CHANGES.txt 906924 2010-02-05 12:43:11Z noble $) >Reporter: Gerald DeConto > Attachments: index.rar, SOLR-1782.2.patch, SOLR-1782.patch, > SOLR-1782.patch, SOLR-1782.test.patch > > > the StatsComponent assumes any field specified in the stats.facet param can > be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems > with a variety of field types, but in the case of multivalued fields it can > either cause erroneous false stats when the number of distinct values is > small, or it can cause ArrayIndexOutOfBoundsException when the number of > distinct values is greater then the number of documents. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-1782: - Assignee: Hoss Man > stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued > fields > - > > Key: SOLR-1782 > URL: https://issues.apache.org/jira/browse/SOLR-1782 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 > Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: > CHANGES.txt 906924 2010-02-05 12:43:11Z noble $) >Reporter: Gerald DeConto >Assignee: Hoss Man > Attachments: index.rar, SOLR-1782.2.patch, SOLR-1782.patch, > SOLR-1782.patch, SOLR-1782.test.patch > > > the StatsComponent assumes any field specified in the stats.facet param can > be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems > with a variety of field types, but in the case of multivalued fields it can > either cause erroneous false stats when the number of distinct values is > small, or it can cause ArrayIndexOutOfBoundsException when the number of > distinct values is greater then the number of documents. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1782) stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued fields
[ https://issues.apache.org/jira/browse/SOLR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533572#comment-13533572 ] Mark Miller commented on SOLR-1782: --- Assigned to hossman in case he has forgotten this issue. He can unassign himself if he doesnt have time. > stats.facet assumes FieldCache.StringIndex - fails horribly on multivalued > fields > - > > Key: SOLR-1782 > URL: https://issues.apache.org/jira/browse/SOLR-1782 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 > Environment: reproduced on Win2k3 using 1.5.0-dev solr ($Id: > CHANGES.txt 906924 2010-02-05 12:43:11Z noble $) >Reporter: Gerald DeConto >Assignee: Hoss Man > Attachments: index.rar, SOLR-1782.2.patch, SOLR-1782.patch, > SOLR-1782.patch, SOLR-1782.test.patch > > > the StatsComponent assumes any field specified in the stats.facet param can > be faceted using FieldCache.DEFAULT.getStringIndex. This can cause problems > with a variety of field types, but in the case of multivalued fields it can > either cause erroneous false stats when the number of distinct values is > small, or it can cause ArrayIndexOutOfBoundsException when the number of > distinct values is greater then the number of documents. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4204) Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments.
[ https://issues.apache.org/jira/browse/SOLR-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533581#comment-13533581 ] Commit Tag Bot commented on SOLR-4204: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1422728 SOLR-4204: Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments. > Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments. > --- > > Key: SOLR-4204 > URL: https://issues.apache.org/jira/browse/SOLR-4204 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4204.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4204) Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments.
[ https://issues.apache.org/jira/browse/SOLR-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533584#comment-13533584 ] Commit Tag Bot commented on SOLR-4204: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1422730 SOLR-4204: Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments. > Make SolrCloud tests more friendly to FreeBSD blackhole 2 environments. > --- > > Key: SOLR-4204 > URL: https://issues.apache.org/jira/browse/SOLR-4204 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4204.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_09) - Build # 2192 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/2192/ Java: 64bit/jdk1.7.0_09 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 30487 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:312: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:120: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java Total time: 65 minutes 56 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.7.0_09 -XX:+UseConcMarkSweepGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533604#comment-13533604
]
Shawn Heisey commented on SOLR-4143:
I concocted something to add to the unit tests, which turned up something
missing in the patch. I think I have worked out all the kinks, so when I
verify that for sure I'll upload a new patch.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
> SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1134 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1134/ All tests passed Build Log: [...truncated 29818 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:312: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/extra-targets.xml:120: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java Total time: 47 minutes 49 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - 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.6.0_37) - Build # 2196 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/2196/ Java: 32bit/jdk1.6.0_37 -server -XX:+UseSerialGC All tests passed Build Log: [...truncated 29866 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:312: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:120: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/core/src/java/org/apache/solr/update/UpdateShardHandler.java Total time: 61 minutes 33 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.6.0_37 -server -XX:+UseSerialGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4197) EDismax allows end users to use local params in q= to override global params
[ https://issues.apache.org/jira/browse/SOLR-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533611#comment-13533611 ] Peter Wolanin commented on SOLR-4197: - Ok, but there is no way to enforce that in the configuration, right? At the very least it's a documentation problem, but I would still consider it a problem that I can't lock this down via solrconfig.xml > EDismax allows end users to use local params in q= to override global params > > > Key: SOLR-4197 > URL: https://issues.apache.org/jira/browse/SOLR-4197 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5, 3.6, 4.0 >Reporter: Peter Wolanin > > Edismax is advertised as suitable to be used to "process advanced user input > directly". Thus, it would seem reasonable to have an application directly > pass user input in the q= parameter to a back-end Solr server. > However, it seems that users can enter local params at the start of q= which > override the global params that the application (e.g. website) may have set > on the query string. Confirmed with Erik Hatcher that this is somewhat > unexpected behavior (though one could argue it's an expected feature of any > query parser) > Proposed fix - add a parameter (e.g. that can be used as an invariant) that > can be passed to inhibit Solr from using local params from the q= parameter. > This is somewhat related to SOLR-1687 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533613#comment-13533613 ] Commit Tag Bot commented on SOLR-4203: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1422746 SOLR-4203: empty the tlog dir without instantiating an updatelog > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4203) An ephemeral directory implementation should cause the transaction log to be ignored on startup.
[ https://issues.apache.org/jira/browse/SOLR-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533614#comment-13533614 ] Commit Tag Bot commented on SOLR-4203: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1422747 SOLR-4203: empty the tlog dir without instantiating an updatelog > An ephemeral directory implementation should cause the transaction log to be > ignored on startup. > > > Key: SOLR-4203 > URL: https://issues.apache.org/jira/browse/SOLR-4203 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4203.patch > > > If you are using something like ram dir, you can restart a node and if no > updates have come in, it will think its up to date but be empty - we should > clear the update log in these cases on startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey updated SOLR-4143:
---
Attachment: SOLR-4143.patch
Updated patch. Added code to MultiCoreExampleTestBase that tests new method.
Test uncovered problems that have now been fixed.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
> SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4194) PingRequestHandler - shards parameter inherited from search handler definition
[ https://issues.apache.org/jira/browse/SOLR-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533525#comment-13533525 ] Shawn Heisey edited comment on SOLR-4194 at 12/17/12 4:28 AM: -- Updated patch for SOLR-4143 fixes this problem as well. Appropriate, since the old patch seems to be what caused it. was (Author: elyograg): Updated patch for SOLR-4143 fixes this problem as well. > PingRequestHandler - shards parameter inherited from search handler definition > -- > > Key: SOLR-4194 > URL: https://issues.apache.org/jira/browse/SOLR-4194 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 > Environment: solr-impl4.1-SNAPSHOT 1421496 - ncindex - 2012-12-13 > 14:56:25 >Reporter: Shawn Heisey > Fix For: 4.1, 5.0 > > > Included in all my cores is a PingRequestHandler named /admin/ping, which I > use to enable/disable the server from the perspective of a load balancer > running haproxy. The handler includes a qt parameter set to /lbcheck. > I have a special core defined (I call it a broker) that includes the shards > parameter in most of its search handler definitions. This includes /select, > /lbcheck, and others. > When the /admin/ping handler is called, the query is sent to the /lbcheck > parameter as expected, which gets distributed because it includes shards. If > one of those shards happens to be down, the handler will give an error > response to the load balancer. > The problem is that the PingRequestHandler seems to inherit the shards > parameter from the search handler it is using, which causes the /admin/ping > request itself to be distributed, which is not what I want. The individual > shards are not used by the load balancer, so they always remain disabled. > This works perfectly in 3.5.0. The official 4.0.0 release has not been > tested. > Config and log data will follow in the comments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4197) EDismax allows end users to use local params in q= to override global params
[
https://issues.apache.org/jira/browse/SOLR-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533643#comment-13533643
]
Peter Wolanin commented on SOLR-4197:
-
Apparently adding a space at the beginning is not a complete solution - I then
get an exception when it's the standard lucene parser:
{code}
Problem accessing /solr/select. Reason:
org.apache.lucene.queryParser.ParseException: Cannot parse '
{!lucene}hello': Encountered " "}" "} "" at line 1, column 9.
Was expecting one of:
"TO" ...
...
...
{code}
> EDismax allows end users to use local params in q= to override global params
>
>
> Key: SOLR-4197
> URL: https://issues.apache.org/jira/browse/SOLR-4197
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.5, 3.6, 4.0
>Reporter: Peter Wolanin
>
> Edismax is advertised as suitable to be used to "process advanced user input
> directly". Thus, it would seem reasonable to have an application directly
> pass user input in the q= parameter to a back-end Solr server.
> However, it seems that users can enter local params at the start of q= which
> override the global params that the application (e.g. website) may have set
> on the query string. Confirmed with Erik Hatcher that this is somewhat
> unexpected behavior (though one could argue it's an expected feature of any
> query parser)
> Proposed fix - add a parameter (e.g. that can be used as an invariant) that
> can be passed to inhibit Solr from using local params from the q= parameter.
> This is somewhat related to SOLR-1687
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter
[
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533658#comment-13533658
]
Shawn Heisey commented on SOLR-4143:
IMHO, this is ready for committer review. If the formatting changes are too
extensive, let me know and I'll make a cleaner patch. I went back to 4x for
the latest patch, but I've had no trouble going back and forth between trunk
and 4x with any of the patches.
> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
> SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the
> URL path from /select to the String argument. It is however doing something
> that I did not expect, which is setting the qt parameter on the query as
> well. Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0
> servers. I am not including the whole exception, because this issue is for
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the
> PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method
> that includes a boolean option deciding whether or not to also set the qt
> parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4206) Solr server should have the self start/stop script
Raintung Li created SOLR-4206: - Summary: Solr server should have the self start/stop script Key: SOLR-4206 URL: https://issues.apache.org/jira/browse/SOLR-4206 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0, 4.0-BETA, 4.0-ALPHA Environment: Linux Reporter: Raintung Li Start the solr server, need manual shell command to start. The start/stop script easy to let admin deploy and control server, especial stop solr server. Directly kill the process, that doesn't good choice. Shell script can let the start/stop more easy, and some parameter can be configuration in the properties file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4206) Solr server should have the self start/stop script
[ https://issues.apache.org/jira/browse/SOLR-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raintung Li updated SOLR-4206: -- Attachment: solr.sh solr.properties Property file -> config for solr start Solr.sh -> Shell script run in the linux. > Solr server should have the self start/stop script > -- > > Key: SOLR-4206 > URL: https://issues.apache.org/jira/browse/SOLR-4206 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 > Environment: Linux >Reporter: Raintung Li > Attachments: solr.properties, solr.sh > > > Start the solr server, need manual shell command to start. > The start/stop script easy to let admin deploy and control server, especial > stop solr server. Directly kill the process, that doesn't good choice. > Shell script can let the start/stop more easy, and some parameter can be > configuration in the properties file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4206) Solr server should have the self start/stop script
[ https://issues.apache.org/jira/browse/SOLR-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raintung Li updated SOLR-4206: -- Attachment: (was: solr.properties) > Solr server should have the self start/stop script > -- > > Key: SOLR-4206 > URL: https://issues.apache.org/jira/browse/SOLR-4206 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 > Environment: Linux >Reporter: Raintung Li > Attachments: solr.properties, solr.sh > > > Start the solr server, need manual shell command to start. > The start/stop script easy to let admin deploy and control server, especial > stop solr server. Directly kill the process, that doesn't good choice. > Shell script can let the start/stop more easy, and some parameter can be > configuration in the properties file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4206) Solr server should have the self start/stop script
[ https://issues.apache.org/jira/browse/SOLR-4206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raintung Li updated SOLR-4206: -- Attachment: solr.properties > Solr server should have the self start/stop script > -- > > Key: SOLR-4206 > URL: https://issues.apache.org/jira/browse/SOLR-4206 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 > Environment: Linux >Reporter: Raintung Li > Attachments: solr.properties, solr.sh > > > Start the solr server, need manual shell command to start. > The start/stop script easy to let admin deploy and control server, especial > stop solr server. Directly kill the process, that doesn't good choice. > Shell script can let the start/stop more easy, and some parameter can be > configuration in the properties file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4164) Result Grouping fails if no hits
[
https://issues.apache.org/jira/browse/SOLR-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533675#comment-13533675
]
Lance Norskog commented on SOLR-4164:
-
I can't recreate it. It may have been another problem I was having: a shard
server ran out of memory during the query and threw an exception to the
distributor. Maybe the group query collection code ignores these remote
exceptions?
> Result Grouping fails if no hits
>
>
> Key: SOLR-4164
> URL: https://issues.apache.org/jira/browse/SOLR-4164
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 4.0
>Reporter: Lance Norskog
>
> In SolrCloud, found a result grouping bug in the 4.0 release.
> A distributed result grouping request under SolrCloud got this result:
> {noformat}
> Dec 10, 2012 10:32:07 PM org.apache.solr.common.SolrException log
> SEVERE: null:java.lang.IllegalArgumentException: numHits must be > 0; please
> use TotalHitCountCollector if you just need the total hit count
> at
> org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1120)
> at
> org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1069)
> at
> org.apache.lucene.search.grouping.AbstractSecondPassGroupingCollector.(AbstractSecondPassGroupingCollector.java:75)
> at
> org.apache.lucene.search.grouping.term.TermSecondPassGroupingCollector.(TermSecondPassGroupingCollector.java:49)
> at
> org.apache.solr.search.grouping.distributed.command.TopGroupsFieldCommand.create(TopGroupsFieldCommand.java:128)
> at
> org.apache.solr.search.grouping.CommandHandler.execute(CommandHandler.java:132)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:339)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
