incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: Heads up - HdfsDirectory in Solr
Date Mon, 17 Jun 2013 15:00:06 GMT
Thanks Mark,

Yeah I knew that the code had been included in the Cloudera Search solution
and that it was going to be headed back to the Lucene/Solr project.  I
believe that collaboration would be great for these complex modules!

However I do have a concern.  The concern I have is that Blur would loose
the ability to change the Directory and BlockCache code in a timely
manner.  While I have no problem with collaborating and sharing, I'm just
concerned that changes that Blur needs may fall on deaf ears (
https://issues.apache.org/jira/browse/LUCENE-2205).  Then we may have to
resort to what we currently do which is patch/override the parts of Lucene
that do not meet our needs.

Basically my biggest concern about moving the directory and block cache
code that Blur utilizes is loss of control.

Aaron



On Mon, Jun 17, 2013 at 10:27 AM, Mark Miller <markrmiller@gmail.com> wrote:

> Hey Blur Devs,
>
> My name is Mark Miller and I'm a Lucene/Solr committer.
>
> I just wanted to give you guys a heads up that we are taking advantage of
> your HdfsDirectory code in https://issues.apache.org/jira/browse/SOLR-4916"Add support
to write and read Solr index files and transaction log files
> to and from HDFS."
>
> It's currently integrated into the Solr section of the code base, but I
> think it would be an interesting idea to eventually move it to a Lucene
> module so that more of us can collaborate on it. I'm in no hurry to get to
> the bottom of that right now, but something for you guys to consider
> joining in on.
>
> To reiterate in a nutshell, I just wanted to let you guys know that we are
> taking advantage of your HdfsDirectory in another Apache project and that
> it might be interesting to collaborate on an HdfsDirectory implementation
> as a Lucene module down the line.
>
> - Mark

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