lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-1028) Automatic core loading unloading for multicore
Date Thu, 06 Dec 2012 00:06:59 GMT

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

Mark Miller commented on SOLR-1028:
-----------------------------------

{noformat}[junit4:junit4]   2> 2265 T632 oasc.SolrCore.initIndex WARNING [collection1]
Solr index directory 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr\collection1\data\index'
doesn't exist. Creating new index...
[junit4:junit4]   2> 2265 T633 oasc.SolrCore.initIndex WARNING [collectionLazy5] Solr index
directory 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr\collection1\data\index'
doesn't exist. Creating new index...
{noformat}

So this may be the race - if collection1 creates it's index dir fast enough, collectionLazy5
prob does not blow up - but it's probably still borked and pointing to collection1's instance
dir - I'm guessing the test is just not catching this problem.
                
> Automatic core loading unloading for multicore
> ----------------------------------------------
>
>                 Key: SOLR-1028
>                 URL: https://issues.apache.org/jira/browse/SOLR-1028
>             Project: Solr
>          Issue Type: New Feature
>          Components: multicore
>    Affects Versions: 4.0, 5.0
>            Reporter: Noble Paul
>            Assignee: Erick Erickson
>             Fix For: 4.1, 5.0
>
>         Attachments: SOLR-1028.patch, SOLR-1028.patch, SOLR-1028_testnoise.patch
>
>
> usecase: I have many small cores (say one per user) on a single Solr box . All the cores
are not be always needed . But when I need it I should be able to directly issue a search
request and the core must be STARTED automatically and the request must be served.
> This also requires that I must have an upper limit on the no:of cores that should be
loaded at any given point in time. If the limit is crossed the CoreContainer must unload a
core (preferably the least recently used core)  
> There must be a choice of specifying some cores as fixed. These cores must never be unloaded


--
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message