lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Lucene v3.6
Date Wed, 02 Jan 2013 18:11:48 GMT
I think I agree with you, Itamar.  I don't think that .NET 3.5 and
Lucene.Net 4.0 will work together.  Additionally, like you, I want Lucene
4.0 to have awesome .NET features as part of the base API, as well as
removing a large part of the unnecessary workaround and optimizations that
are in the code because of bugs in the JVM, since none really apply to the
CLR.  I think that reworking Lucene.Net in this way might be more
interesting to members of the community and maybe even some of our own
committers, motivating people to contribute more either with code or in
planning/discussions.

I know that a there are a lot of our users who are stuck with .NET 3.5,
even though it's 5-6 years old, because of their company's business
requirements.  I think we need to wind up maintaining two separate
branches, a 3.x and 4.x branch, where the 3.x versions of Lucene support
.NET 3.5 and 4.0 and the 4.x versions of Lucene support .NET 4.0/4.5 only.

With a 3.x branch, I would like to see continued porting from 3.0.3 to
later versions, up to and including 3.6, if easily possible with .NET 3.5.
 In the case that a full version can't be ported, optimizations and bug
fixes should be backported wherever possible.  I know that it sort of goes
against what you were saying earlier about our current amount of resources
we have, but I feel that dramatically dropping support for .NET 3.5 would
be a mistake.  Since it's a very boring job and likely something few
people/nobody wants to do, I'd be willing to do most of the 3.x porting and
maintaining myself, so others can completely focus on Lucene 4.x.

This might require a vote, sure, and definitely input from the community,
but ultimately, I think that there's no real way around dropping support
for .NET 3.5 in Lucene 4.x.


Thanks,
Christopher



On Wed, Jan 2, 2013 at 12:13 AM, Oren Eini (Ayende Rahien) <
ayende@ayende.com> wrote:

> Just to remind you, 3.5 came out in *2007*
> That is six years ago, and long enough to require 4.0 (came out in 2010, 3
> years ago)
>
> On Wed, Jan 2, 2013 at 10:06 AM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > Honestly I think we should completely drop .NET 3.5 support. If we had
> more
> > time and more committers that may would have been a nice thing to have,
> but
> > given the current amount of resources that we have, we should really put
> > everything we've got into taking the largest strides we can towards a
> > proper release conforming to the latest Java Lucene.
> >
> > There's enough people using .NET 4 already anyway, and whoever doesn't
> will
> > either move soon or could use the .NET 3.5 version of Lucene 3.1. IMO the
> > penalty of supporting both or not using .NET4 features because of it
> > doesn't worth it.
> >
> > Having said that, I'm all for porting Lucene 4.1 to .NET with .NET
> specific
> > approaches, such as the async API, getters/setters syntax, lambdas etc.
> > This has to be done in a way that will still allow us to keep up to date
> > with the current code-base - meaning that would need to be quite a loud
> > process.
> >
> > I assume that would require a vote?
> >
> >
> > On Wed, Jan 2, 2013 at 2:14 AM, Christopher Currens <
> > currens.chris@gmail.com
> > > wrote:
> >
> > > I would like to add async/await, but I think adding a MMapDirectory,
> > first,
> > > is more important, and also something we could do now for the 3.x
> > versions
> > > of lucene.  I know we've looked at it before (LUCENE-425, I think?),
> and
> > it
> > > was turned down because it had poor performance.  I've tested a quick
> > port
> > > that I wrote and it performs the same under light load (8 threads) as
> it
> > > does under heavy load (250 threads), able to complete 6000 queries in
> 74
> > > seconds.  It performs the same as SimpleFSDirectory when it comes to
> > light
> > > load, but the SimpleFSDirectory performs horribly under heavy load,
> where
> > > the 250 threads querying 6000 times total took about 160 seconds.
> > >
> > > Another problem with supporting both .NET 3.5 and .NET 4.0, is that it
> > > makes it more difficult in some respects to add things like methods
> that
> > > return Task<T>, since it's not present in 3.5.  I think we need to
> > maintain
> > > two separate ports, a 3.x branch and a 4.x branch, although we don't
> > have a
> > > committer base that is active enough to do that.  The 3.x branch could
> > > support .NET 3.5 and 4.0, where the 4.0 branch would only support .NET
> > 4.0.
> > >  If you look at the differences between 3.0.3 and 3.1, there are huge
> > > performance optimizations that have been done, and to not give those to
> > > .NET 3.5 users seems to be a wasted opportunity, in my opinion.  A lot
> of
> > > the difficulties that come with porting Lucene 4.0 into .NET 3.5 come
> in
> > > the later versions of the 3.x branch, probably around 3.5 or 3.6.
> > >
> > >
> > > On Tue, Jan 1, 2013 at 3:43 PM, Nicholas Paldino [.NET/C# MVP] <
> > > casperOne@caspershouse.com> wrote:
> > >
> > > > As a somewhat related issue with .NET 4.0, are there plans to move to
> > > > asynchronous calls at any point for what are now blocking I/O
> > operations?
> > > >
> > > > Task<T> in 4.0 has made removing blocking I/O operations in C#/.NET
> 4.0
> > > > fairly simple (although not as simple as C# 4.5 with async/await and
> > core
> > > > framework changes to support Task<T>).
> > > >
> > > > I ask because I'm thinking the throughput and/or performance of of
> > > > Lucene.NET would be increased dramatically (by reducing waits on
> > > file-based
> > > > I/O operations) but it would be a large architectural change.
> > > >
> > > > Perhaps it's something to keep in mind for the future.
> > > >
> > > >  - Nicholas Paldino
> > > >
> > > > On Jan 1, 2013, at 5:38 PM, "Christopher Currens" <
> > > currens.chris@gmail.com>
> > > > wrote:
> > > >
> > > > > There are issues that need to be discussed about the 4.0 port and
> > being
> > > > > able to continue support of .NET 3.5.  I can only think of one
> > example
> > > > > right now, but I've looked through most of the code for lucene 4.0,
> > and
> > > > > there's a *very* heavy use of variance that would be difficult to
> > > > maintain
> > > > > outside of .NET 4.x.  If you want a good example of this, check out
> > the
> > > > > lucene.util.ast package and its usages.  This isn't the only area
> > that
> > > > uses
> > > > > both contravariance and covariance, but it's the only one I could
> > think
> > > > of
> > > > > off of the top of my head.
> > > > >
> > > > > I started porting parts of it, just to see what could be done
> > (nothing
> > > > > significant).  It's been a month or so since I worked on it, so my
> > > memory
> > > > > of what I found is foggy.  The variance was the biggest thing I saw
> > > that
> > > > > was an issue, but I think there were a few other things.  I'd have
> to
> > > > look
> > > > > at it again to see.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Christopher
> > > > >
> > > > >
> > > > > On Tue, Jan 1, 2013 at 12:50 AM, Itamar Syn-Hershko <
> > > itamar@code972.com
> > > > >wrote:
> > > > >
> > > > >> The general direction should be to put most of the efforts on
a v4
> > > port
> > > > >> (4.1 probably...) and to start finding pieces in the codebase
we
> can
> > > > easily
> > > > >> isolate and .NET-ify. Mostly readers, writers, structures and
> > > > conversions.
> > > > >>
> > > > >> Re git on apache - I believe you should ask infra.
> > > > >>
> > > > >>
> > > > >> On Tue, Dec 18, 2012 at 6:54 PM, Christopher Currens <
> > > > >> currens.chris@gmail.com> wrote:
> > > > >>
> > > > >>> Don't think I've forgotten about this.  While I have no idea
how
> > git
> > > > >> under
> > > > >>> Apache looks like, I have a lot of comments on Lucene 3.6
(and
> 4.0)
> > > > that
> > > > >> I
> > > > >>> need to discuss on this mailing list directly relating to
the
> > porting
> > > > >> work
> > > > >>> and the future direction of lucene.net.  I've had an email
in my
> > > > drafts
> > > > >>> folder for about 3 weeks now but this time of year has been
so
> > busy I
> > > > >>> haven't had a chance to finish it.  Soon, though, I hope.
> > > > >>>
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Christopher
> > > > >>>
> > > > >>>
> > > > >>> On Sat, Dec 15, 2012 at 1:09 PM, Prescott Nasser <
> > > > geobmx540@hotmail.com
> > > > >>>> wrote:
> > > > >>>
> > > > >>>> Hey Guys -  I've been quietly working in the background
on
> > > > >> administrative
> > > > >>>> stuff for a while. I really only have two things on my
to-do
> list
> > -
> > >  -
> > > > >>> What
> > > > >>>> does git under apache look like? I can't remember who
asked
> this,
> > > but
> > > > I
> > > > >>>> know I owe digging up the answer- Lucene 3.6 - planning,
moving
> > > > >> forward (
> > > > >>>>
> > https://github.com/apache/lucene-solr/compare/5261b571...e4402c22c
> > > ).
> > > > >> Do
> > > > >>>> we just want to start picking things off and committing
them?
> Are
> > > > there
> > > > >>>> other refactoring issues we want to tackle with 3.6?
We should
> > make
> > > > >> jira
> > > > >>>> tickets and start tracking. Happy holidays everyone!
~Prescott
> > > > >>
> > > >
> > > >
> > >
> >
>

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