lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Looking for community guidance on SOLR-4872
Date Mon, 08 Jul 2013 13:14:34 GMT
Dear Lucene Community,

I note that this email has received no response, and the JIRA no further
discussion, since June 19th. As an occasional contributor to this
community, I think that this is unreasonable. My personal belief is that
the Apache Way calls for you to decide something here: use a vote if
needed. You might decide to do _nothing_ at all, but you won't just leave
me waving in the breeze. I suppose that _I_ could call a vote here, but as
a non-committer it would seem presumptuous of me. Also, I might not find a
committer willing to act on it.

Respectfully,

Benson



On Wed, Jun 19, 2013 at 8:49 AM, Benson Margulies <bimargulies@gmail.com>wrote:

> I write to seek guidance from the dev community on SOLR-4872.
>
> This JIRA concerns lifecycle management for Solr schema components:
> tokenizers, token filters, and char filters.
>
> If you read the comments, you'll find three opinions from committers. What
> follows are précis: read the JIRA to get the details.
>
> Hoss is in favor of having close methods on these components and arranging
> to have them called when a schema is torn down. Hoss is opposed to allowing
> these objects to be SolrCoreAware.
>
> Yonik is opposed to having such close methods and prefers SolrCoreAware,
> or something like it, or letting component implementors use finalizers.
>
> Rob Muir thinks that there should be a fix to the related LUCENE-2145,
> which I see as complementary to this.
>
> So, here I am. I'm not a committer. I'm a builder of Solr plugins, and,
> from that standpoint, I think that there should be a lifecycle somehow,
> because I try to apply a general principle of avoiding finalizers, and
> because in some cases their unpredictable schedule can be a practical
> problem.
>
> Is there a committer in this community who is willing to work with me on
> this? As things are, I can't see how to proceed, since I'm suspended
> between two committers with apparently opposed views.
>
> I have already implemented what I think of as the hard part, and, indeed,
> the foundation of either approach. I have a close lifecycle that extends
> down to the IndexSchema object and the TokenizerChain. So it remains to
> decide whether that should in turn call ordinary close methods on the
> tokenizers, token filters, and char filters, or rather look for some
> optional lifecycle interface.
>
>
>

Mime
View raw message