lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Biestro (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-350) Manage Multiple SolrCores
Date Wed, 27 Feb 2008 17:45:51 GMT

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

henrib edited comment on SOLR-350 at 2/27/08 9:44 AM:
-------------------------------------------------------------

Otis, reading your requirements, I'd be considering using a Solr core (the "metacore") to
handle an indexed version of multicore.xml; if you have a few thousands indices, it might
be convenient to use queries in some occasions to select/retrieve/operate on one/many of them.
The xml version of the multicore persistent file could be written at application/multicore
shutdown and the Lucene based one could be recreated at application/multicore startup; creating
a new index would just induce creating a new document in the multicore core (and in fact all
CRUD operations could be handled that way) and we'd benefit from Solr autocommit feature &
al, tackling your functional requirements reusing well-known capabilities & code.
This also removes the "hack" loop used to find a core to work with when issuing a multicore/admin
request (and the getDefaultCore call). Got a patch running for this now if this seems interesting.


On configuring easily the data/index dir from multicore.xml, it seems we all agree that variables
definitions should be able to allow just that; the non-extensible version of the feature (see
previous comment)- where we dont allow the user to augment the environment but only expose
'solr.multicore.*'- did not trigger any comment yet, Otis/Hoss/Ryan what do you think of it
?

      was (Author: henrib):
    Otis, reading your requirements, I'd be considering using a Solr core to handle an indexed
version of multicore.xml; if you have a few thousands indices, it might be convenient to use
queries in some occasions to select/retrieve one/many of them.
The xml version of the multicore persistent file could be written at application/multicore
shutdown and the Lucene based one could be recreated at application/multicore startup; creating
a new index would just induce creating a new document in the multicore core (and in fact all
CRUD operations could be handled that way) and we'd benefit from Solr autocommit feature &
al, tackling your functional requirements reusing well-known capabilities & code.
For ~10 indices/cores, this seems like overkill though... 

On configuring easily the data/index dir from multicore.xml, it seems we all agree that variables
definitions should be able to allow just that; the non-extensible version of the feature (see
previous comment)- where we dont allow the user to augment the environment but only expose
'solr.multicore.*'- did not trigger any comment yet, Otis/Hoss/Ryan what do you think of it
?
  
> Manage Multiple SolrCores
> -------------------------
>
>                 Key: SOLR-350
>                 URL: https://issues.apache.org/jira/browse/SOLR-350
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Ryan McKinley
>         Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch,
SOLR-350-Naming.patch, SOLR-350-Naming.patch, solr-350.patch, solr-350.patch, solr-350.patch,
solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch
>
>
> In SOLR-215, we enabled support for more then one SolrCore - but there is no way to use
them yet.
> We need to make some interface to manage, register, modify avaliable SolrCores

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


Mime
View raw message