Re: Solr.xml parameters
logging watcher threshold - No clue what this does. You can set this to, for example, 'WARN', to only record WARN-level or above log messages. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr.xml parameters
Thanks, I came to the same conclusion after I had a chance to dig into the code, but it's nice to have it confirmed. On Wed, Jul 24, 2013 at 5:11 AM, Alan Woodward a...@flax.co.uk wrote: logging watcher threshold - No clue what this does. You can set this to, for example, 'WARN', to only record WARN-level or above log messages. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr.xml parameters
On Jul 23, 2013, at 4:07 PM, Erick Erickson erickerick...@gmail.com wrote: I'm trying to finalize some of the documentation for the release of the docs that'll happen Real Soon Now so I need to nail these down. How close are these definitions for the following parameters? leaderVoteWait - when SolrCloud is starting up, how long we'll wait before assuming that no leader will identify itself. No, this is how long the system will wait on startup to see all the known replicas for a shard show up. This is to be sure they all participate in the election and the best candidate is chosen. This is protection against bringing back a stale shard on a cluster restart and having it become leader right off. genericCoreNodeNames - I have no idea. This makes it so that node names are not based on the address of the node, but on a generic core_nodename_n (or something like that). When a different machine takes over serving that core, things will be much less confusing. managementPath - no clue I think this might be dead - i see a bit of code around picking it up, but nothing that does anything with it. roles - why do I care to set this parameter? Future param for SolrCloud or a way for users to mark nodes for their own use. coreNodeName - how is this different than name? Is it something anyone should mess with and why? For SolrCloud - let's you specifically label a name rather than have them generated for you (either by address or the generic names from the genericCoreNodeNames setting. This let's you allow a different machine to take over for a core that already has a node name and was served from a different machine. logging watcher threshold - No clue what this does. Seems to be the default log level the UI will use if you don't want it to be WARN. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr.xml parameters
Mark: Thanks, I looked over the code and got them mostly right, I'll update the Confluence page to reflect more accurate information... On Wed, Jul 24, 2013 at 9:32 AM, Mark Miller markrmil...@gmail.com wrote: On Jul 23, 2013, at 4:07 PM, Erick Erickson erickerick...@gmail.com wrote: I'm trying to finalize some of the documentation for the release of the docs that'll happen Real Soon Now so I need to nail these down. How close are these definitions for the following parameters? leaderVoteWait - when SolrCloud is starting up, how long we'll wait before assuming that no leader will identify itself. No, this is how long the system will wait on startup to see all the known replicas for a shard show up. This is to be sure they all participate in the election and the best candidate is chosen. This is protection against bringing back a stale shard on a cluster restart and having it become leader right off. genericCoreNodeNames - I have no idea. This makes it so that node names are not based on the address of the node, but on a generic core_nodename_n (or something like that). When a different machine takes over serving that core, things will be much less confusing. managementPath - no clue I think this might be dead - i see a bit of code around picking it up, but nothing that does anything with it. roles - why do I care to set this parameter? Future param for SolrCloud or a way for users to mark nodes for their own use. coreNodeName - how is this different than name? Is it something anyone should mess with and why? For SolrCloud - let's you specifically label a name rather than have them generated for you (either by address or the generic names from the genericCoreNodeNames setting. This let's you allow a different machine to take over for a core that already has a node name and was served from a different machine. logging watcher threshold - No clue what this does. Seems to be the default log level the UI will use if you don't want it to be WARN. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Solr.xml parameters
I'm trying to finalize some of the documentation for the release of the docs that'll happen Real Soon Now so I need to nail these down. How close are these definitions for the following parameters? distribUpdateConnTimeout - the time any update will wait for a node to respond to an indexing request. distribUpdateSoTimeout - The socket read timeout before the thread assumes the read operation will never complete due to some kind of networking problem. leaderVoteWait - when SolrCloud is starting up, how long we'll wait before assuming that no leader will identify itself. genericCoreNodeNames - I have no idea. managementPath - no clue roles - why do I care to set this parameter? coreNodeName - how is this different than name? Is it something anyone should mess with and why? logging watcher threshold - No clue what this does. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2324) SolrCloud solr.xml parameters are not persisted by CoreContainer.
[ https://issues.apache.org/jira/browse/SOLR-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2324: -- Component/s: SolrCloud Summary: SolrCloud solr.xml parameters are not persisted by CoreContainer. (was: CoreContainer.persist(Writer w) method doesn't write all parameters) SolrCloud solr.xml parameters are not persisted by CoreContainer. - Key: SOLR-2324 URL: https://issues.apache.org/jira/browse/SOLR-2324 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Massimo Schiavon Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-2324.patch Parameters like solr/@zkHost and solr/cores/@hostPort are ignored. -- This message is automatically generated by JIRA. 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-2324) SolrCloud solr.xml parameters are not persisted by CoreContainer.
[ https://issues.apache.org/jira/browse/SOLR-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2324. --- Resolution: Fixed Thanks Massimo! SolrCloud solr.xml parameters are not persisted by CoreContainer. - Key: SOLR-2324 URL: https://issues.apache.org/jira/browse/SOLR-2324 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Massimo Schiavon Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-2324.patch Parameters like solr/@zkHost and solr/cores/@hostPort are ignored. -- This message is automatically generated by JIRA. 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
