lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-1028) Automatic core loading unloading for multicore
Date Tue, 30 Oct 2012 22:42:13 GMT


Hoss Man commented on SOLR-1028:

Erick: note the following recent jenkins failure...

java.lang.AssertionError: reload exception doesn't refer to prolog 프롤로그에서는 콘텐츠가
허용되지 않습니다.
        at __randomizedtesting.SeedInfo.seed([F661F6E616E4E41:959CD4968591C045]:0)
        at org.junit.Assert.assertTrue(
        at org.apache.solr.core.CoreContainerCoreInitFailuresTest.testFlowBadFromStart(

ant test  -Dtestcase=CoreContainerCoreInitFailuresTest -Dtests.method=testFlowBadFromStart
-Dtests.seed=F661F6E616E4E41 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ko -Dtests.timezone=GB

The problem seems to be that when you cleaned up what exceptions get thrown, you also changed
what logic is used in the test to verify that the expected error was generated so that it
relies on a specific (english) string "prolog", and when we run in some locals that specific
string is not included in the wraped XML exceptions - hence the previous usage of e.getSystemId().indexOf("solrconfig.xml")
in that test since that is a garunteed property of the exception that is in our control.
> Automatic core loading unloading for multicore
> ----------------------------------------------
>                 Key: SOLR-1028
>                 URL:
>             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
> 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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message