lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject RE: Lucene.net release mode
Date Mon, 12 Jun 2017 21:04:03 GMT
Vincent,

Running the tests in Release mode must be done to ferret out the issues that occur when the
compiler removes Debug.Assert statements that change state. Apparently, these statements are
not removed in Java, so we have to be vigilant about testing this condition in .NET to ensure
it will work right without them.

I think it is a good idea to find a better way to do this than the Debuggable attribute -
at the time I was just trying to get over all of the hurdles to make the tests run successfully
so we could release, and this was the first solution I could find that worked. The tests rely
on specific information to be in the stack trace in order to succeed, and the way it is determined
is different between .NET Framework and .NET Core. See:

Lucene.Net.TestFramework.Util.StackTraceHelper
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyInCommit.Eval()
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyInSync.Eval()
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyOnFlush.Eval()
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyOnTermVectors.Eval()

As long as we can find a way to make these tests work, I have no issue with changing it. IMO,
using stack trace information is a horrible thing to test for, anyway - it would be better
to inject some kind of test helper that tracks what phase the index writer is in and read
its state directly from the test, but I am not sure how difficult that would be. Perhaps there
is a way to use a decorator pattern around the components in question to track whether a specific
method is currently being executed...?

Thanks,
Shad Storhaug (NightOwl888)


-----Original Message-----
From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar
Syn-Hershko
Sent: Monday, June 12, 2017 9:45 PM
To: dev@lucenenet.apache.org
Subject: Re: Lucene.net release mode

Sounds legit to me. Generating and distributing pdb's is the way to go, unless there is something
preventing us from doing this. Shad? Connie?

--

Itamar Syn-Hershko
Freelance Developer & Consultant
Elasticsearch Partner
Microsoft MVP | Lucene.NET PMC
http://code972.com | @synhershko <https://twitter.com/synhershko> http://BigDataBoutique.co.il/

On Mon, Jun 12, 2017 at 4:55 PM, Van Den Berghe, Vincent < Vincent.VanDenBerghe@bvdinfo.com>
wrote:

> Hello everyone,
>
> I'm seeing the following in AssemblyInfo.cs:
>
> // LUCENENET NOTE: This attribute is required to disable optimizations 
> so the // 
> Lucene.Net.Tests.Index.TestIndexWriterExceptions.TestExceptionsDuringC
> ommit()
> test
> // can read the stack trace information, otherwise the test fails.
> [assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | 
> DebuggableAttribute.DebuggingModes.DisableOptimizations)]
>
>
> This effectively disables optimizations in release mode.
> However, removing this attribute is removed doesn't seem to affect the 
> "TestExceptionsDuringCommit" test. Moreover, this test doesn't seem to 
> read stack trace information, unless there is something that I'm missing.
>
> If stack trace information is needed in release mode, one could 
> consider generating PDB information. Yes, optimization will sometimes 
> cause the information to be incorrect, but the probability of having 
> bugs in release mode that can't be reproduced in debug mode is relatively small, IMHO.
>
> What say the esteemed colleages?
>
> Vincent
>
Mime
View raw message