Hmm, I'm leery of giving this class a name: I don't want to call
attention to the fact that you can turn off CMS's throttling, even
inside Lucene's test-framework.
Mike McCandless
http://blog.mikemccandless.com
On Thu, Nov 20, 2014 at 10:51 AM, Mark Miller wrote:
> If it was just to work arou
If it was just to work around Solr, I think the fix should be in Solr. But
we ship the Lucene test framework module, and Solr is not doing anything
too crazy here at all. So it makes more sense to me to make the Lucene test
module more friendly and consumable rather than doing a hack in Solr.
- Ma
It's a hack, true. I thought about creating the public class in
LuceneTestCase, but it seemed weird to be changing the lucene functionality to
work around an issue in the way Solr instantiates things. But you're right,
this does mean that we lose a bit of test coverage in Solr, so maybe your
This kind of sucks though right? What if we changed it from an anon class
in Lucene instead and then wouldn't it work in more cases and we don't lose
this new test functionality as a Lucene test module consumer?
eg
public static final class DoesNotStallConcurrentMergeScheduler extends
Con
Thanks Alan!
Mike McCandless
http://blog.mikemccandless.com
On Thu, Nov 20, 2014 at 5:12 AM, Alan Woodward wrote:
> I committed a fix. There's now a check in newRandomConfig() to see if
> there's a "$" in the merge scheduler class name, and if there is it just
> uses CMS instead.
>
> Alan Woo
I committed a fix. There's now a check in newRandomConfig() to see if there's
a "$" in the merge scheduler class name, and if there is it just uses CMS
instead.
Alan Woodward
www.flax.co.uk
On 19 Nov 2014, at 19:07, Alan Woodward wrote:
> So digging in… Solr instantiates the merge scheduler
So digging in… Solr instantiates the merge scheduler via it's ResourceLoader,
which takes a class name. The random indexconfig snippet sets the classname to
whatever the value of ${solr.tests.mergeScheduler} is. This is set in
SolrTestCaseJ4.newRandomConfig():
System.setProperty("solr.tests.
Oh, I also saw this before committing, was confused, ran "ant clean
test" in solr directory, and it passed, so I thought "ant clean" fixed
it ... I guess not.
With this change, in LuceneTestCase's newIndexWriterConfig, I
sometimes randomly subclass ConcurrentMergeScheduler (to turn off
merge throt
I think this might be to do with Mike's changes in r1640457, but for some
reason I can't up from svn or the apache git repo at the moment so I'm not
certain.
Alan Woodward
www.flax.co.uk
On 19 Nov 2014, at 17:05, Chris Hostetter wrote:
>
> Apologies -- I haven't been following the commits cl
Apologies -- I haven't been following the commits closely this week.
Does anyone have any idea what changed at the low levels of the Solr
testing class hierarchy to cause these failures in a variety of tests?
: SolrCore 'collection1' is not available due to init failure: Error
: instantiating
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2215/
2 tests failed.
REGRESSION: org.apache.solr.SampleTest.testSimple
Error Message:
SolrCore 'collection1' is not available due to init failure: Error
instantiating class: 'org.apache.lucene.util.LuceneTestCase$3'
Stack Trace:
11 matches
Mail list logo
