[ 
https://issues.apache.org/jira/browse/SOLR-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925654#action_12925654
 ] 

Mike Anderson commented on SOLR-880:
------------------------------------

I'm not entirely clear on how START would differ from CREATE, and how STOP 
would differ from UNLOAD. I gather there are certain tasks that occur in CREATE 
that would be skipped in a START command, and that a START command could only 
be issued on a STOPPED core, which had previously been CREATED (but not 
UNLOADED). 

This issue hasn't been touched in over a year, is it still thought to be the 
right approach to improving multicore? What are the saving of START/STOP vs 
CREATE/UNLOAD? is it an issue of speed? memory? 

> SolrCore should have a STOP option and a lazy startup option
> ------------------------------------------------------------
>
>                 Key: SOLR-880
>                 URL: https://issues.apache.org/jira/browse/SOLR-880
>             Project: Solr
>          Issue Type: Improvement
>          Components: multicore
>            Reporter: Noble Paul
>            Assignee: Shalin Shekhar Mangar
>
> * We must have an option to STOP and START a core. 
> * a core should have an option of loadOnStartup=true|false. default should be 
> true
> * A list command which can give the names of all cores and some meta 
> information like status
> If there are too many cores (tens of thousands) where each of them may be 
> used occassionally, we should not load all of them at once. In the runtime I 
> should be able to STOP and START a core on demand. A listing command would 
> let me know which one is present and what is up and what is down. A stopped 
> core must not use any resource

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to