lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wyatt Barnett <>
Subject Re: Last failing tests remain to fix!
Date Wed, 08 Apr 2015 22:09:18 GMT
Thanks for the update Itamar -- this sounds exciting.

A few notes / questions from the build side of things here:

First, I'm not as hung up on persistently failing tests as the tests we get
intermittent failures on. I suspect some of the below will address this.

Second, what do we want to do about the 112 or so ignored tests? I think
some are marked as long-running via the [LongRunningTest] attribute but
there are probably some ignored failures in that mix.

Third, regarding the sub-projects, what does the structure look like so I
can get that integrated into the TeamCity setup? Or should I noodle on it
and propose one?

Thanks for all the help from everyone getting things this far.

On Wed, Apr 8, 2015 at 1:07 PM, Itamar Syn-Hershko <>

> Hey all,
> We are nearly there -- we are this close to a release!
> We have only about 30 failing tests now in the core, and I'd like to push
> hard during the next few days so we can get a beta out next week.
> I'd appreciate your help with this!
> I've narrowed down several failing tests that require some digging, if
> folks can assign those to themselves and send us PRs fixing those tests,
> that would help a lot!
> 1. Lucene.Net.Search.TestNumericRangeQuery32.TestInfiniteValues()
> and Lucene.Net.Search.TestNumericRangeQuery64.TestInfiniteValues() --
> specifically it seems like Double and Float NaNs are treated differently
> between C# and Java and therefore the failing tests. Or there is a bug in
> the inner implementation handling those queries.
> 2. TestLucene40DocValuesFormat has a few failing tests, probably exposing
> data corruption in one of the codec components. I believe this is contained
> in the 40DocValues tests so the scope isn't huge but I could be wrong.
> 3. TestLucene42DocValuesFormat has two tests failing with output of lines
> like "Fail: frozenHash=182658 vs h=5124052". Something is off in computing
> the hashes of the nodes, or maybe the node construction is faulty (which is
> a serious bug). Hashing is done in Lucene.Net.Fst.NodeHash<T>, that'll be a
> good starting point. Also see
> 4. There seem to be some concurrency issues with file handling, probably on
> the part that is in charge of acquiring and releasing locks. In particular
> see TestDocValuesFormat,
> .TestShardSearching.TestSimple(),
> TestBufferedIndexInput.TestSetBufferSize(),
> TestLockFactory.TestStressLocks(),
> TestLockFactory.TestStressLocksNativeFSLockFactory()
> 5. RegexpQuery seems to be broken, I believe the underlying automaton
> implementation doesn't emit the terms correctly. See the failures in
> TestRegexpQuery and TestRegexpRandom.
> 6. Similar but probably unrelated failing test is
> at TestSpanMultiTermQueryWrapper.TestFuzzy2()
> 7. An interesting failure to investigate is here:
> TestIndexableBinaryStringTools.TestEncodedSortability() -- probably a
> simple porting fail, a subtle Java <--> C# mismatch that we haven't
> noticed.
> Additionally, any help with porting the subprojects would be great. Some
> folks took some subprojects under their wings and never reported back. If
> you could either complete the work, or donate whatever you have done so
> far, that would be great.
> As always, get the code from here: --
> work on your fork and send us a PR when ready, with a good description of
> what you've done.
> To see the list of currently failing tests in real-time, go here (you can
> login as guest):
> Thanks, and happy searching,
> --
> Itamar Syn-Hershko
> | @synhershko <>
> Freelance Developer & Consultant
> Lucene.NET committer and PMC member

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message