[
https://issues.apache.org/jira/browse/SOLR-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510786#comment-13510786
]
Dawid Weiss commented on SOLR-1028:
-----------------------------------
It all depends where things went wrong. If it's a test that failed and you're
at the after-test or after-suite level then I think it'd be possible to tell
that a previous failure has occurred. In fact, it's currently being done in the
code -- TestRuleMarkFailure.java contains code to intercept the "status" of the
wrapped code. You need to be careful about a few things (assumptions are
propagated as exceptions, for example) but otherwise it's pretty
straightforward. One problem with the current use of this rule is that it is
always called *last* to detect failures from other rules. It's a
chicken-and-egg problem that doesn't have clean solutions... or so I tend to
think -- I'd need to take a look at the runner again and thing if maybe this
flag could be part of the randomized context.
The problem in general is that you could create a test rule that intercepts
exceptions (or failures) from tests and cancels them out (simply by eating up
the thrown exception). So it's not just the fact of throwing an exception from
a test that matters -- it's crossing the boundary from the suite class back to
the runner. If this sounds complex and twisted to you it's because it kind of
is...
bq. You almost always have to dig for the true failure because so many failures
can keep cores from being closed
One thing that should help here is that the exceptions are always reported in
the order in which they were captured and chained. So the first exception in
the failure report is the one that happened first... I realize it's still a lot
of digging, sorry.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
