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