You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erick Erickson <er...@gmail.com> on 2013/07/23 22:07:53 UTC
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Solr.xml parameters
Posted by Erick Erickson <er...@gmail.com>.
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 <al...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Solr.xml parameters
Posted by Alan Woodward <al...@flax.co.uk>.
>
>
> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Solr.xml parameters
Posted by Erick Erickson <er...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> On Jul 23, 2013, at 4:07 PM, Erick Erickson <er...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Solr.xml parameters
Posted by Mark Miller <ma...@gmail.com>.
On Jul 23, 2013, at 4:07 PM, Erick Erickson <er...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org