[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] [Commented] (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=16237732#comment-16237732
]
Nawab Zada Asad iqbal commented on SOLR-11581:
--
Amrit,
After reading your question, I am now realizing that `compoundFile` is not what
i understood it to be; and it is a temporary file during indexing. My
perception was based on this comment in a `solrconfig` which comes out of the
box.
{code:java}
{code}
> 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
[jira] [Commented] (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 commented on SOLR-11581: -- 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
[jira] [Commented] (SOLR-11504) Provide a config to restrict number of indexing threads
[ https://issues.apache.org/jira/browse/SOLR-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16234401#comment-16234401 ] Nawab Zada Asad iqbal commented on SOLR-11504: -- [~dsmiley] You have duplicated it with "SOLR-3585" . Isn't that JIRA very broad scoped? The scope in the current ticket (11504) is to restrict the requests from Solr to Lucene's `IndexWriter`. My initial thoughts are: IndexWriter.getDocument(s) and updateDocument(s) is mostly used from `DirectUpdateHandler2` (It is also used in `FileBasedSpellChecker.java` : which seems to be a non-routine scenario). For the purpose of fixing SOLR-11504, it seems enough to use a counting semaphore (or any similar structure) to control the flow of indexing requests from `DirectUpdateHandler2` to `IndexWriter`. What do you think? > Provide a config to restrict number of indexing threads > > > Key: SOLR-11504 > URL: https://issues.apache.org/jira/browse/SOLR-11504 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.3, 6.0, 7.0 >Reporter: Nawab Zada Asad iqbal >Priority: Major > Original Estimate: 336h > Remaining Estimate: 336h > > For heavy indexing load (through REST api), Solr does not have any way to > restrict number of threads. There used to be a config in lucene to restrict > number of threads but that has been removed since > https://issues.apache.org/jira/browse/LUCENE-6659 . > For example, in my bulk indexing scenario, within few minutes, my solr server > had created 300 parallel threads each writing its own segment. The result was > tons of small segments getting flushed to disk (as total RAM limit was > reached quickly by sum of all segments), and solr has to spend time later to > merge them into reasonable sizes. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-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=16226940#comment-16226940 ] Nawab Zada Asad iqbal commented on SOLR-11581: -- I just thought, that my proposed fix (making constructor public) is in Lucene. Should i have opened a Lucene bug? > 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] [Commented] (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=16226882#comment-16226882 ] Nawab Zada Asad iqbal commented on SOLR-11581: -- Exactly. During bulk indexing scenario, we would like to save the Indexer from useless processing. I don't have any stats on the impact on efficiency but if Lucene is doing it, then probably there is some impact. > 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] [Created] (SOLR-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR
Nawab Zada Asad iqbal created SOLR-11581: Summary: 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] [Created] (SOLR-11580) With hl=true and fl=id+score, Solr tries to highligh all the results on first call
Nawab Zada Asad iqbal created SOLR-11580: Summary: With hl=true and fl=id+score, Solr tries to highligh all the results on first call Key: SOLR-11580 URL: https://issues.apache.org/jira/browse/SOLR-11580 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.5 Reporter: Nawab Zada Asad iqbal Priority: Minor Normal solr behavior in distributed solr shards is to bring id and score on first request and then request full row of results and highlighted fields in the second call after sorting the results (on aggregator node). In Solr 6 or earlier a change was introduced to skip the second call if fields to return only has id and score. However, this misses one edge case when hl=true; and asks the shards to highlight all the results on the first call, which is really inefficient. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11504) Provide a config to restrict number of indexing threads
Nawab Zada Asad iqbal created SOLR-11504: Summary: Provide a config to restrict number of indexing threads Key: SOLR-11504 URL: https://issues.apache.org/jira/browse/SOLR-11504 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.0, 6.0, 5.3 Reporter: Nawab Zada Asad iqbal For heavy indexing load (through REST api), Solr does not have any way to restrict number of threads. There used to be a config in lucene to restrict number of threads but that has been removed since https://issues.apache.org/jira/browse/LUCENE-6659 . For example, in my bulk indexing scenario, within few minutes, my solr server had created 300 parallel threads each writing its own segment. The result was tons of small segments getting flushed to disk (as total RAM limit was reached quickly by sum of all segments), and solr has to spend time later to merge them into reasonable sizes. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16179831#comment-16179831 ] Nawab Zada Asad iqbal commented on SOLR-11297: -- It seems that this error is difficult to reproduce. I tried Luiz's script on my Mac laptop and wasn't able to reproduce this issue even after decreasing the 'sleep' between iteration to `0.005`. I tried it on a production like machine (which is similar to what I had done last month although using an haproxy instead of a command line script) and I was able to hit the above error however my cores were still loaded by the 'Core' thread and were functional. Last month when initially I hit this issue, my server was giving the above 'Lock held by this virtual machine' error and also they were **not** usable. Unfortunately, I don't have access to those specific machines anymore. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Fix For: 7.1 > > Attachments: SOLR-11297.patch, SOLR-11297.patch, SOLR-11297.patch, > SOLR-11297.sh, solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. > One critical detail to this issue: The cores are all perfectly functional. > If somebody is seeing an error message that results in a core not working at > all, then it is likely a different issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16176719#comment-16176719 ] Nawab Zada Asad iqbal commented on SOLR-11297: -- [~erickerickson] i would have loved to test it, but my test cluster which naturally hit this issue has been reclaimed and i will not have access to another for another week. I am looking forward to solr 7.0; as we haven't rolled solr 6 to production yet. Locally, I can mock the repeated pings by Luiz's script but if you have already tested with it, then that is not much useful. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: SOLR-11297.patch, SOLR-11297.patch, SOLR-11297.sh, > solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175113#comment-16175113 ] Nawab Zada Asad iqbal commented on SOLR-11297: -- FWIW, on my cluster with constant haproxy pings, i was hitting this issue 9/10 times. And the core was not even usable. So my issue was slightly different from Shawn, but I hope that your fix will cover for all the issues. Looking forward for the fix. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: SOLR-11297.patch, SOLR-11297.patch, SOLR-11297.sh, > solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172298#comment-16172298 ] Nawab Zada Asad iqbal commented on SOLR-11297: -- [~erickerickson] [~luiz.armesto]'s repro is very similar to mine. I had run solr6.6.1 in a standalone environment without any issue. I stumbled on this issue while trying to start cores on a server which was constantly being pinged by haproxy, even before it had loaded the (empty) cores. > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: SOLR-11297.patch, SOLR-11297.sh, solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11297) Message "Lock held by this virtual machine" during startup. Solr is trying to start some cores twice
[ https://issues.apache.org/jira/browse/SOLR-11297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16170301#comment-16170301 ] Nawab Zada Asad iqbal commented on SOLR-11297: -- [~elyograg] [~erickerickson] I am curious about how frequently this behavior is reproducible. Is rest of the world running 6.6.1 totally fine and only 4 of us seeing this issue? I see LUCENE-7959 was fixed to give a better error, however in my case the file is actually getting created so I am not hitting the permission issue. One way to debug will be to downgrade to an earlier version and try to reproduce the error. Can someone suggest which version should I start with? > Message "Lock held by this virtual machine" during startup. Solr is trying > to start some cores twice > - > > Key: SOLR-11297 > URL: https://issues.apache.org/jira/browse/SOLR-11297 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6 >Reporter: Shawn Heisey >Assignee: Erick Erickson > Attachments: solr6_6-startup.log > > > Sometimes when Solr is restarted, I get some "lock held by this virtual > machine" messages in the log, and the admin UI has messages about a failure > to open a new searcher. It doesn't happen on all cores, and the list of > cores that have the problem changes on subsequent restarts. The cores that > exhibit the problems are working just fine -- the first core load is > successful, the failure to open a new searcher is on a second core load > attempt, which fails. > None of the cores in the system are sharing an instanceDir or dataDir. This > has been verified several times. > The index is sharded manually, and the servers are not running in cloud mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
[ https://issues.apache.org/jira/browse/SOLR-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122043#comment-16122043 ] Nawab Zada Asad iqbal commented on SOLR-11200: -- `autoThrottle` also looks good! > provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle > --- > > Key: SOLR-11200 > URL: https://issues.apache.org/jira/browse/SOLR-11200 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nawab Zada Asad iqbal >Priority: Minor > Attachments: SOLR-11200.patch, SOLR-11200.patch > > > This config can be useful while bulk indexing. Lucene introduced it > https://issues.apache.org/jira/browse/LUCENE-6119 . -- 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-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
[ https://issues.apache.org/jira/browse/SOLR-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120198#comment-16120198 ] Nawab Zada Asad iqbal edited comment on SOLR-11200 at 8/9/17 4:53 PM: -- [~sarkaramr...@gmail.com] I just reviewed your patch, it looks good. For the name, what about `enableAutoIOThrottle` ? I will test it now and report if I see any issues. PS: I edited it after realizing that the long config name is initiating from LUCENE code. My previous suggestion was `enableIOThrottle` was (Author: niqbal): [~sarkaramr...@gmail.com] I just reviewed your patch, it looks good. For the name, what about `enableIOThrottle` ? The word `Auto` does not seem necessary. I will test it now and report if I see any issues. > provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle > --- > > Key: SOLR-11200 > URL: https://issues.apache.org/jira/browse/SOLR-11200 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nawab Zada Asad iqbal >Priority: Minor > Attachments: SOLR-11200.patch, SOLR-11200.patch > > > This config can be useful while bulk indexing. Lucene introduced it > https://issues.apache.org/jira/browse/LUCENE-6119 . -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
[ https://issues.apache.org/jira/browse/SOLR-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120220#comment-16120220 ] Nawab Zada Asad iqbal commented on SOLR-11200: -- [~sarkaramr...@gmail.com] which branch are you working from 6.6 or 7? I am getting an error while applying the patch. > provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle > --- > > Key: SOLR-11200 > URL: https://issues.apache.org/jira/browse/SOLR-11200 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nawab Zada Asad iqbal >Priority: Minor > Attachments: SOLR-11200.patch, SOLR-11200.patch > > > This config can be useful while bulk indexing. Lucene introduced it > https://issues.apache.org/jira/browse/LUCENE-6119 . -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
[ https://issues.apache.org/jira/browse/SOLR-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120198#comment-16120198 ] Nawab Zada Asad iqbal commented on SOLR-11200: -- [~sarkaramr...@gmail.com] I just reviewed your patch, it looks good. For the name, what about `enableIOThrottle` ? The word `Auto` does not seem necessary. I will test it now and report if I see any issues. > provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle > --- > > Key: SOLR-11200 > URL: https://issues.apache.org/jira/browse/SOLR-11200 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nawab Zada Asad iqbal >Priority: Minor > Attachments: SOLR-11200.patch, SOLR-11200.patch > > > This config can be useful while bulk indexing. Lucene introduced it > https://issues.apache.org/jira/browse/LUCENE-6119 . -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11200) provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle
Nawab Zada Asad iqbal created SOLR-11200: Summary: provide a config to enable disable ConcurrentMergeSchedule.doAutoIOThrottle Key: SOLR-11200 URL: https://issues.apache.org/jira/browse/SOLR-11200 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.6 Reporter: Nawab Zada Asad iqbal Priority: Minor This config can be useful while bulk indexing. Lucene introduced it https://issues.apache.org/jira/browse/LUCENE-6119 . -- 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
