lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Carpenter" <stcarpen...@gmail.com>
Subject Re: Current Status/Plans for Lucene.Net 2.3
Date Wed, 08 Oct 2008 15:19:26 GMT
Doug,
I was able to spend some time today looking at my test failures.  They are:
TestIndexWriter.TestMaxThreadPriority() - fails resetting the thread
priority in the finally() clause with the exception: "Thread is dead;
priority cannot be accessed."  I'm running on a dual-core machine - I
haven't investigated yet to see if this is the issue.
TestSpans.TestSpanNearOrdered0[2-5]() - as expected.
TestIndexWriterLockRelease.TestDummy() - this fails during TearDown because
the __test_dir variable is not null due to a previous execution of
_TestIndexWriterLockRelease.  Each test runs successfully when I execute
them individually.  I think adding a this.__test_dir = null; statement to
the end of the TearDown method will fix this issue - I believe it is due to
JUnit and NUnit differences that you alluded to in an earlier message.

I ignored the TestHugeRamFile test based on your comments.

Sean

On Tue, Oct 7, 2008 at 1:43 PM, Max Metral <max@artsalliancelabs.com> wrote:

> Not to toss too much water on NAnt, but why not use MSBuild instead?
> That way you can use the existing core sln/project files, but still
> don't need VStudio.
>
> -----Original Message-----
> From: Doug Sale [mailto:dougsale@gmail.com]
> Sent: Tuesday, October 07, 2008 1:00 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Current Status/Plans for Lucene.Net 2.3
>
> Sean,
>
> AFAIK, no one is working on that.  I think that would be useful - it
> would
> encourage development by people who don't want to or are not able to use
> Visual Studio.
>
> Regarding test failures, I expect
> TestStressIndexing.TestStressIndexAndSearching(),
> TestSpans.TestSpanNearOrdered0[2-5](), and
> TestHugeRamFile.TestHugeFile() to
> fail.
>
> Where does your experience diverge?
>
> BTW, I don't believe there is an issue with the latter test.  When I
> reduce
> the size of the file by a factor of 2 the test succeeds on my machines.
> I
> believe it is merely an "eating all your memory and virtual memory"
> issue.
>
> As I mentioned, previously - I'm investigating the tests listed above,
> but
> welcome any and all assistance.
>
> Thanks.
>
>
> On Mon, Oct 6, 2008 at 10:21 AM, Sean Carpenter
> <stcarpenter@gmail.com>wrote:
>
> > I was able to apply all of the suggested patches and I currently get 7
> test
> > failures.  I haven't had a chance to dig into them yet, but one thing
> that
> > took me some time was getting everything set up to build and run the
> tests.
> >  I was thinking of contributing a NAnt build file that would make it
> easier
> > for people to get set up and running.
> > Is there any interest in that (or is someone already working on it)?
> >
> > Thanks,
> > Sean
> >
> > On Fri, Oct 3, 2008 at 7:35 AM, Sean Carpenter <stcarpenter@gmail.com
> > >wrote:
> >
> > > Doug,Thanks for the update.  I'll apply those patches this weekend
> and
> > see
> > > what I come up with.
> > >
> > > Sean
> > >
> > >
> > > On Thu, Oct 2, 2008 at 3:29 PM, Doug Sale <dougsale@gmail.com>
> wrote:
> > >
> > >> Sean,
> > >>
> > >> Currently, there are two people working on the 2.3.1 port - myself,
> and
> > >> DIGY.  Neither of us are committers, but the understanding is that
> we
> > soon
> > >> will be.
> > >>
> > >> IMHO, there are 7 outstanding patches across 6 JIRA issues that
> should
> > be
> > >> applied to SVN HEAD:
> > >> LUCENENET-135 SupportClass.patch
> > >> LUCENENET-143 TestStressIndexing2.patch, FieldsReader.patch
> > >> LUCENENET-145 DocumentsWriter.patch
> > >> LUCENENET-146 SegmentTermPositionVector.patch
> > >> LUCENENET-152 SegmentInfos.patch
> > >> LUCENENET-155 SetUp.patch
> > >>
> > >> After applying said patches, there remain unit test failures in
> > >> TestStressIndexing.TestStressIndexAndSearching() (intermittent
> > exceptions)
> > >> and TestSpans.TestSpanNearOrdered0[2-4]() (2 search results'
> relevance
> > >> ranking are swapped).
> > >>
> > >> I am currently attempting to resolve these issues.  Any and all
> > >> assistance,
> > >> however, is welcome.  A first step would be to apply these patches
> to
> > the
> > >> SVN HEAD and verify that your test results match mine.
> > >>
> > >> Additionally, on most machines TestHugeRamFile.TestHugeFile() will
> fail
> > >> due
> > >> to a lack of physical memory (and might crash VS and/or your
> system).
> > >>  This
> > >> can be alleviated by reducing the size requirement in the unit
> test.
> > >>
> > >> The current committers are responsible for reviewing these patches,
> > >> applying
> > >> them when worthy, and determining when the code is ready for
> release.
> > >>
> > >> Also - I have a local version of the code with the 2.3.2 changes
> ported,
> > >> ready-to-go, once the current batch of patches have been applied
> and the
> > >> remaining issues have been resolved.
> > >>
> > >> -Doug
> > >>
> > >>
> > >> On Thu, Oct 2, 2008 at 6:38 AM, Sean Carpenter
> <stcarpenter@gmail.com
> > >> >wrote:
> > >>
> > >> > I am curious as to the current state of the 2.3.1 port.  These
> doesn't
> > >> seem
> > >> > to be much activity on the dev list or in the JIRA, and there are
> > >> several
> > >> > outstanding patches in the JIRA.  When I checked out the code
> this
> > >> morning
> > >> > and ran the tests, I got a bunch of failures and an exception
> that
> > >> caused
> > >> > NUnit to close.
> > >> > I'd really like to see Lucene.Net keep up with the Java version
> as we
> > >> have
> > >> > a
> > >> > couple of existing projects and a few new ones at work that
> utilize
> > >> Lucene.
> > >> >  What can I do to help?  Is there a way to get the current
> outstanding
> > >> > patches applied to the trunk so that we have a common base to
> work
> > from?
> > >> >  I'm happy to work on patches for the outstanding test failures,
> once
> > >> it's
> > >> > easier to determine which ones are still outstanding.
> > >> >
> > >> > Any thoughts?
> > >> >
> > >> > Thanks,
> > >> > Sean Carpenter
> > >> >
> > >>
> > >
> > >
> >
>

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