lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Sale" <dougs...@gmail.com>
Subject Re: Current Status/Plans for Lucene.Net 2.3
Date Wed, 08 Oct 2008 16:09:38 GMT
Sean,

I have a patch for TestIndexWriterLockRelease.TestDummy(), but I forgot to
include it in the list (sorry).

The patch is TestIndexWriterLockRelease.patch and is available here:
https://issues.apache.org/jira/browse/LUCENENET-154

In the interest of clarity, here is the revised patch list:

- PATCHES TO SVN HEAD FOR LUCENE.NET 2.3.1 -

LUCENENET-135 SupportClass.patch
LUCENENET-143 TestStressIndexing2.patch, FieldsReader.patch
LUCENENET-145 DocumentsWriter.patch
LUCENENET-146 SegmentTermPositionVector.patch
LUCENENET-152 SegmentInfos.patch
LUCENENET-154 TestIndexWriterLockRelease.patch
LUCENENET-155 SetUp.patch

Regarding the test failure in TestIndexWriter.TestMaxThreadPriority():

I can't replicate this error.  If you currently have, or come up with, a
patch for this issue that would be great.  Either way, this issue should be
logged in JIRA.  If you don't have a JIRA account, you can get one here:
http://issues.apache.org/jira/secure/Signup!default.jspa

Thanks,
Doug

On Wed, Oct 8, 2008 at 10:19 AM, Sean Carpenter <stcarpenter@gmail.com>wrote:

> 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