[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626522#action_12626522 ] henrib edited comment on SOLR-725 at 8/28/08 4:30 AM: - added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; minor modifications so calling close is usually performed outside of the synchronized block on cores (to reduce contention). change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. was (Author: henrib): added remaining operations and their mappings in CoreAdminRequest; added specific tests to check refCount / number of aliases are kept in sync; change: unloadCore is now a *core* operation, it unloads the core (removes all its aliases thus really closes/unloads the core); unaliasCore is an *alias* operation and only removes the alias. 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.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626209#action_12626209 ] henrib edited comment on SOLR-725 at 8/27/08 10:51 AM: -- bq. A rename with null is a bad usecase . We should not allow it rename is a package private method that is called when we unalias a core from its name, asking it to pick a new one from its aliases. However, is there is no alias to that core, the core has no way to name itself anymore but it may still be serving requests; thus the 'null' to indicate that case. I'd expect this to be rare but the case exists nevertheless. was (Author: henrib): bq. A rename with null is a bad usecase . We should not allow it rename is a package private method that is called when we unalias a core from its name, asking it to pick a new one from its aliases. However, is there is no alias to that core, the core has no way to name itself anymore but it may still be serving requests. I'd expect this to be rare but the case exists nevertheless. 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 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 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635 ] noble.paul edited comment on SOLR-725 at 8/26/08 12:04 AM: --- bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says core should be independent of how it is named . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior , * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command *must not* succeed if the new name is already registered for another core. If a user wish to do so UNLOAD that core , or if it is an alias UNALIAS that name before trying this. * The solr.xml core tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. * SolrQueryRequest should have a method to let handlers know through which alias this request is made was (Author: noble.paul): bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says core should be independent of how it is named . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior , * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command *must not* succeed if the new name is already registered for another core. If a user wish to do so UNLOAD that core , or if it is an alias UNALIAS that name before trying this. * The solr.xml core tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. 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 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.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635 ] noble.paul edited comment on SOLR-725 at 8/26/08 12:07 AM: --- bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Whose usecases are not ver clear * Because of this feature some very useful methods are implemented inconsistently. As Yonik says core should be independent of how it is named . But as things stand we are removing some commonly useful methods OK. Now that we already have ALIAS as a feature I propose the following behavior , * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command *must not* succeed if the new name is already registered for another core. If a user wish to do so UNLOAD that core , or if it is an alias UNALIAS that name before trying this. * The solr.xml core tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name (use UNLOAD to do that). * SolrQueryRequest should have a method to let handlers know through which alias this request is made was (Author: noble.paul): bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says core should be independent of how it is named . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior , * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command *must not* succeed if the new name is already registered for another core. If a user wish to do so UNLOAD that core , or if it is an alias UNALIAS that name before trying this. * The solr.xml core tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. * SolrQueryRequest should have a method to let handlers know through which alias this request is made 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 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
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625976#action_12625976 ] noble.paul edited comment on SOLR-725 at 8/26/08 10:28 PM: --- bq.Which ones? Is it something that impacts solr-561 somehow? Sorry for not being clear. The widely used methods getName() in SolrCore and CoreDescriptor is what I am referring to . The symlink method is least invasive . The reason being , getName() is far more useful than the alias feature itself (think of JMX cores are identified by name. and there are more places ) . Using this approach we get all the benefits of alias and we lose nothing. Moreover the implementation is easy was (Author: noble.paul): bq.Which ones? Is it something that impacts solr-561 somehow? Sorry for not being clear. The widely used methods getName() in SolrCore and CoreDESCRIPTORis what I am referring to . The symlink method is least invasive . The reason being , getName() is far more useful than the alias feature itself (think of JMX cores are identified by name. and there are more places ) . Using this approach we get all the benefits of alias and we lose nothing. Moreover the implementation is easy 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 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 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625635#action_12625635 ] noble.paul edited comment on SOLR-725 at 8/25/08 10:51 PM: --- bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says core should be independent of how it is named . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior , * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command *must not* succeed if the new name is already registered for another core. If a user wish to do so UNLOAD that core , or if it is an alias UNALIAS that name before trying this. * The solr.xml core tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. was (Author: noble.paul): bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says core should be independent of how it is named . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command should not succeed if the new name is already registered for another core. * The solr.xml core tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. 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 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 *
