[jira] [Comment Edited] (SOLR-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR
[ https://issues.apache.org/jira/browse/SOLR-11581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16234474#comment-16234474 ] Nawab Zada Asad iqbal edited comment on SOLR-11581 at 11/3/17 3:15 PM: --- Thanks Amrit, and Michael. I am already doing most of what you are recommending. I want to write a blog on it, once I successfully upgrade to solr 7 and also look forward to your Amrit's article. -Though, we don't use "useCompondFile" for the sake of better query performance. - (EDIT, I later found that this perception of 'useCompoundFile' is wrong) Michael: In our current design, we bulk index all the accumulated documents, then merge explicitly to an optimal number of segments (10 or so). Only then we start live indexing and query traffic to the servers (there are some intermediate steps to replace solrconfig and also index for the time taken during bulk indexing). In earlier experiments with older Solr versions, keeping merging ON while bulk indexing slowed down the whole process. was (Author: niqbal): Thanks Amrit, and Michael. I am already doing most of what you are recommending. I want to write a blog on it, once I successfully upgrade to solr 7 and also look forward to your Amrit's article. -Though, we don't use "useCompondFile" for the sake of better query performance. - (EDIT, I later found that this perception is wrong) Michael: In our current design, we bulk index all the accumulated documents, then merge explicitly to an optimal number of segments (10 or so). Only then we start live indexing and query traffic to the servers (there are some intermediate steps to replace solrconfig and also index for the time taken during bulk indexing). In earlier experiments with older Solr versions, keeping merging ON while bulk indexing slowed down the whole process. > NoMergeScheduler ctor should be public for allowing instantiation from SOLR > --- > > Key: SOLR-11581 > URL: https://issues.apache.org/jira/browse/SOLR-11581 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nawab Zada Asad iqbal >Priority: Minor > > There are scenarios where a SOLR user may want to use NoMergeScheduler. > However, it is not possible to use it today, since its constructor is private > and solrconfig.xml requires a Scheduler with public constructor. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR
[ https://issues.apache.org/jira/browse/SOLR-11581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16234474#comment-16234474 ] Nawab Zada Asad iqbal edited comment on SOLR-11581 at 11/3/17 3:12 PM: --- Thanks Amrit, and Michael. I am already doing most of what you are recommending. I want to write a blog on it, once I successfully upgrade to solr 7 and also look forward to your Amrit's article. -Though, we don't use "useCompondFile" for the sake of better query performance. - (EDIT, I later found that this perception is wrong) Michael: In our current design, we bulk index all the accumulated documents, then merge explicitly to an optimal number of segments (10 or so). Only then we start live indexing and query traffic to the servers (there are some intermediate steps to replace solrconfig and also index for the time taken during bulk indexing). In earlier experiments with older Solr versions, keeping merging ON while bulk indexing slowed down the whole process. was (Author: niqbal): Thanks Amrit, and Michael. I am already doing most of what you are recommending. I want to write a blog on it, once I successfully upgrade to solr 7 and also look forward to your Amrit's article. Though, we don't use "useCompondFile" for the sake of better query performance. Michael: In our current design, we bulk index all the accumulated documents, then merge explicitly to an optimal number of segments (10 or so). Only then we start live indexing and query traffic to the servers (there are some intermediate steps to replace solrconfig and also index for the time taken during bulk indexing). In earlier experiments with older Solr versions, keeping merging ON while bulk indexing slowed down the whole process. > NoMergeScheduler ctor should be public for allowing instantiation from SOLR > --- > > Key: SOLR-11581 > URL: https://issues.apache.org/jira/browse/SOLR-11581 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nawab Zada Asad iqbal >Priority: Minor > > There are scenarios where a SOLR user may want to use NoMergeScheduler. > However, it is not possible to use it today, since its constructor is private > and solrconfig.xml requires a Scheduler with public constructor. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
