[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626841#action_12626841
]
Noble Paul commented on SOLR-725:
---------------------------------
We are building a feature as explained in SOLR-727. The idea is to make the
replication admin page of master show the details of slaves as well (details
like which version of the index is used by each slave etc. etc) instead of
going to each slave to know that . So each slave registers itself with the
master by providing the url of itself the url will be of this format
http://<host>:<port>/<web-app>/<corename>/replication.
to make this feature work we expect the url to be fixed. If the url is a
moving target it may just not work.(or it will be difficult)
Another important feature is SOLR-561 itself . The configuration takes the
masterUrl . The url has to be fixed for the lifetime of the solr core.If we
make the url invalid this again will not work
Going forward , we will have to see a Solr as a whole network of systems of
multiple masters slaves and multiple shards . unlike the current strategy of
seeing each instance as an island. We are making the first step in that
direction . Assuming that we will be using urls to communicate with each other
it is important to have a reliable/fixed url for each core.
henri .I am yet to see an argument of why the symlink approach will not meet
your usecases other than the point that it is not very 'elegant' . I have made
my points on why the alias (in the current form and the way you propose) is
going to make my usecases difficult .
> CoreContainer/CoreDescriptor/SolrCore cleansing
> -----------------------------------------------
>
> Key: SOLR-725
> URL: https://issues.apache.org/jira/browse/SOLR-725
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3
> Reporter: Henri Biestro
> Attachments: solr-725.patch, solr-725.patch, solr-725.patch
>
>
> These 3 classes and the name vs alias handling are somewhat confusing.
> The recent SOLR-647 & SOLR-716 have created a bit of a flux.
> This issue attemps to clarify the model and the list of operations.
> h3. CoreDescriptor: describes the parameters of a SolrCore
> h4. Definitions
> * has one name
> ** The CoreDescriptor name may represent multiple aliases; in that
> case, first alias is the SolrCore name
> * has one instance directory location
> * has one config & schema name
> h4. Operations
> The class is only a parameter passing facility
> h3. SolrCore: manages a Lucene index
> h4. Definitions
> * has one unique *name* (in the CoreContainer)
> ** the *name* is used in JMX to identify the core
> * has one current set of *aliases*
> ** the name is the first alias
> h4. Name & alias operations
> * *get name/aliases*: obvious
> * *alias*: adds an alias to this SolrCore
> * *unalias*: removes an alias from this SolrCore
> * *name*: sets the SolrCore name
> ** potentially impacts JMX registration
> * *rename*: picks a new name from the SolrCore aliases
> ** triggered when alias name is already in use
> h3. CoreContainer: manages all relations between cores & descriptors
> h4. Definitions
> * has a set of aliases (each of them pointing to one core)
> ** ensure alias uniqueness.
> h4. SolrCore instance operations
> * *load*: makes a SolrCore available for requests
> ** creates a SolrCore
> ** registers all SolrCore aliases in the aliases set
> ** (load = create + register)
> * *unload*: removes a core idenitified by one of its aliases
> ** stops handling the Lucene index
> ** all SolrCore aliases are removed
> * *reload*: recreate the core identified by one of its aliases
> * *create*: create a core from a CoreDescriptor
> ** readies up the Lucene index
> * *register*: registers all aliases of a SolrCore
>
> h4. SolrCore alias operations
> * *swap*: swaps 2 aliases
> ** method: swap
> * *alias*: creates 1 alias for a core, potentially unaliasing a
> previously used alias
> ** The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
> * *unalias*: removes 1 alias for a core
> ** The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
> * *rename*: renames a core
> h3. CoreAdminHandler: handles CoreContainer operations
> * *load*/*create*: CoreContainer load
> * *unload*: CoreContainer unload
> * *reload*: CoreContainer reload
> * *swap*: CoreContainer swap
> * *alias*: CoreContainer alias
> * *unalias*: CoreContainer unalias
> * *rename*: CoreContainer rename
> * *persist*: CoreContainer persist, writes the solr.xml
> * *stauts*: returns the status of all/one SolrCore
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
