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 <markrmil...@gmail.com> wrote:
> 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.
>
> - Mark
>
> On Thu Nov 20 2014 at 10:02:42 AM Alan Woodward <a...@flax.co.uk> wrote:
>>
>> 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
>> <luc...@mikemccandless.com> wrote:
>>>
>>> Thanks Alan!
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Thu, Nov 20, 2014 at 5:12 AM, Alan Woodward <a...@flax.co.uk> 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 <a...@flax.co.uk> 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: dev-unsubscr...@lucene.apache.org
>>> >
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> >
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> >
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>> >
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to