lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [lucenenet] NightOwl888 commented on pull request #313: Fix/random seed simple
Date Sun, 02 Aug 2020 16:03:08 GMT

NightOwl888 commented on pull request #313:
URL: https://github.com/apache/lucenenet/pull/313#issuecomment-667692212


   > Adding this before the test runs
   NUnit.Framework.Internal.Randomizer.InitialSeed = NUnit.Framework.Internal.TestExecutionContext.CurrentContext.CurrentTest.Seed;
   
   > seems to stop the tests erroring. Is this hiding something tho? If there is one random
using a different seed, this shouldn't cause an issue.
   
   Before the test runs how? I tried adding it to the beginning of the test and it didn't
seem to make a difference.
   
   I took a deep dive into this and there were several contributors causing these tests to
fail. 
   
   - The culture sensitivity was broken by the change of default when we switched to `J2N.Character`
in 4.8.0-beta00008 without specifying `CultureInfo.InvariantCulture`. Fixed in #321.
   - The `ThaiWordBreaker` wasn't set up to handle surrogate pairs, so would fail when there
were surrogate pairs in the random input. Fixed in #322.
   - Something is causing `ThaiAnalyzer` to fail when using concurrency. This one I haven't
found the cause, but being that the behavior changed when I added a `.Clone()` to each of
the prototypes, I suspect the issue lies in `ICU4N.RuleBasedBreakIterator` where it loads
the Thai break engine. Adding locking also seems to make it fail less, but it still does occasionally.
We need to add some concurrency tests to ICU4N for `BreakIterator` when using Thai to see
if we can make it fail - there were no tests for concurrency in ICU4J.
   
   There doesn't appear to be anything wrong with `BaseTokenStreamTestCase`, but when I commented
out the concurrency check inside `CheckAnalysisConsistency()`, I ran the `TestRandomHugeStrings()`
and `TestRandomStrings() tests 10000 times in a row each without a failure. Putting the concurrency
check back in makes the failure happen after a few hundred runs.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



Mime
View raw message