[
https://issues.apache.org/jira/browse/SOLR-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13653098#comment-13653098
]
Mark Miller commented on SOLR-4655:
-----------------------------------
Yeah, I'm currently working on another branch that has a fix for SOLR-4745, so
that stuff has been moved in what I'm mainly looking at.
Unfortunetly, we don't seem to have a test that will catch that yet (at least
on my dev machine) - unless a more rare chaos monkey test can trigger it?
As a side note since I'm reminded: It also seemed like the shard splitting
tests could occasionaly pass even though no split had been ordered - you noted
some time ago above I was missing some critical code in a merge up, but I still
got some passing runs at the time. It did fail commonly, but it seems like no
split should be an easy all the time fail.
> The Overseer should assign node names by default.
> -------------------------------------------------
>
> Key: SOLR-4655
> URL: https://issues.apache.org/jira/browse/SOLR-4655
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Fix For: 4.3, 5.0
>
> Attachments: SOLR-4655.patch, SOLR-4655.patch, SOLR-4655.patch,
> SOLR-4655.patch, SOLR-4655.patch, SOLR-4655.patch
>
>
> Currently we make a unique node name by using the host address as part of the
> name. This means that if you want a node with a new address to take over, the
> node name is misleading. It's best if you set custom names for each node
> before starting your cluster. This is cumbersome though, and cannot currently
> be done with the collections API. Instead, the overseer could assign a more
> generic name such as nodeN by default. Then you can easily swap in another
> node with no pre planning and no confusion in the name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
