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
suggestion is better.
Alan Woodward
www.flax.co.uk
On 20 Nov 2014, at 14:38, Mark Miller wrote:
> 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
> ConcurrentMergeScheduler {
> @Override
> protected synchronized void maybeStall() {
> }
> }
>
> Mark
>
> On Thu Nov 20 2014 at 5:17:31 AM Michael McCandless
> <[email protected]> wrote:
> Thanks Alan!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Nov 20, 2014 at 5:12 AM, Alan Woodward <[email protected]> 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 Woodward
> > www.flax.co.uk
> >
> >
> > On 19 Nov 2014, at 19:07, Alan Woodward wrote:
> >
> > 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.mergeScheduler",
> > iwc.getMergeScheduler().getClass().getName());
> >
> > And I guess you can't call Class.newInstance() on an anonymous class?
> >
> > Alan Woodward
> > www.flax.co.uk
> >
> >
> > On 19 Nov 2014, at 18:10, Michael McCandless wrote:
> >
> > 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 throttling) in the random IWC that's returned. Does this make
> >
> > Solr unhappy? Why is Solr trying to instantiate the merge scheduler
> >
> > class that's already instantiated on IWC? I'm confused...
> >
> >
> > Mike McCandless
> >
> >
> > http://blog.mikemccandless.com
> >
> >
> >
> > On Wed, Nov 19, 2014 at 1:00 PM, Alan Woodward <[email protected]> wrote:
> >
> > 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 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 class: 'org.apache.lucene.util.LuceneTestCase$3'
> >
> >
> > : Caused by: org.apache.solr.common.SolrException: Error instantiating
> >
> > class: 'org.apache.lucene.util.LuceneTestCase$3'
> >
> > : at
> >
> > org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:532)
> >
> > : at
> >
> > org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:517)
> >
> > : at
> >
> > org.apache.solr.update.SolrIndexConfig.buildMergeScheduler(SolrIndexConfig.java:289)
> >
> > : at
> >
> > org.apache.solr.update.SolrIndexConfig.toIndexWriterConfig(SolrIndexConfig.java:214)
> >
> > : at org.apache.solr.update.SolrIndexWriter.<init>(SolrIndexWriter.java:77)
> >
> > : at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:64)
> >
> > : at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:529)
> >
> > : at org.apache.solr.core.SolrCore.<init>(SolrCore.java:796)
> >
> > : ... 8 more
> >
> > : Caused by: java.lang.IllegalAccessException: Class
> >
> > org.apache.solr.core.SolrResourceLoader can not access a member of class
> >
> > org.apache.lucene.util.LuceneTestCase$3 with modifiers ""
> >
> > : at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:109)
> >
> > : at java.lang.Class.newInstance(Class.java:368)
> >
> > : at
> >
> > org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:529)
> >
> > : ... 15 more
> >
> >
> > : [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=SampleTest
> >
> > -Dtests.method=testSimple -Dtests.seed=2E6E8F9ADADFEACF -Dtests.multiplier=2
> >
> > -Dtests.slow=true -Dtests.locale=ja_JP_JP_#u-ca-japanese
> >
> > -Dtests.timezone=Europe/Lisbon -Dtests.asserts=true
> >
> > -Dtests.file.encoding=US-ASCII
> >
> >
> >
> > -Hoss
> >
> > http://www.lucidworks.com/
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: [email protected]
> >
> > For additional commands, e-mail: [email protected]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: [email protected]
> >
> > For additional commands, e-mail: [email protected]
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
