You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by GitBox <gi...@apache.org> on 2020/08/02 16:03:08 UTC

[GitHub] [lucenenet] NightOwl888 commented on pull request #313: Fix/random seed simple

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