Via fucit.org I grabbed the test logs reported from sarowe's build machine:
ant test -Dtestcase=DistanceUnitsTest -Dtests.seed=2A4319779B036482 -Dtests.slow=true -Dtests.locale=ar-KW -Dtests.timezone=Asia/Srednekolymsk -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 Does not reproduce. I suspect this is another case where we have a Solr test that extends LuceneTestCase instead of SolrTestCaseJ4. It has been just fine up till now but recently seems to be a problem with regards to logging. There are a ton of such tests, e.g. UUIDFieldTest and 100+ more. Perhaps the underlying issue can be fixed instead of requiring Solr's tests to extend SolrTestCaseJ4. Shrug. On Fri, Sep 7, 2018 at 2:49 PM Dawid Weiss <[email protected]> wrote: > > My word I hope not. Async in this context is all relative to log4J. > > [...] > > If the same logger is used between tests in > > If it's asynchronous then this probably means the log is left in some > buffer where it's then picked up by another thread and passed to a > collector (an appender in log4j nomenclature). If this is the case > then I don't see how you can guarantee logs don't cross test > boundaries or even suite boundaries. We'd need some sort of > log4j-internal "flush" to ensure logs are flushed before the end of > the test/ suite. > > I'd love to be able to help out with this, but I'll be pretty much > away for the weekend. Maybe next week I'll find some time. > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
