LUCENE-2145, How to proceed on Tokenizer.close()

[Benson Margulies <bi...@gmail.com>]

Since LUCENE-2145 is of specific practical interest to me, I'd like to pitch in.

However, it raises a bit of a compatibility thicket.

There are, I think, two rough approaches:

1) redefine close() on TokenStream to have the less surprising
semantics of 'don't use this object after it has been closed', and
change existing callers to close the reader for themselves, or provide
a closeReader().

2) leave close() as is, and define, well, 'reallyCloseIMeanIt()'.

I'm happy to do grunt work here, but I'm obviously not the person to
decide which of these is appropriate and tasteful.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: LUCENE-2145, How to proceed on Tokenizer.close()

[Robert Muir <rc...@gmail.com>]

i still think we can fix this without changing APIs: something like just
having the tokenizer close the reader in end() instead of close().

Then remove close() from the consumer lifecycle (its only called e.g. when
analyzer.close() releases its CLoseableThreadLocals of reused streams).

Index: lucene/core/src/java/org/apache/lucene/analysis/Tokenizer.java
===================================================================
--- lucene/core/src/java/org/apache/lucene/analysis/Tokenizer.java
(revision 1491309)
+++ lucene/core/src/java/org/apache/lucene/analysis/Tokenizer.java
(working copy)
@@ -47,6 +47,10 @@
     this.input = input;
   }

+  @Override
+  public void close() throws IOException {
+  }
+
   /**
    * {@inheritDoc}
    * <p>
@@ -55,7 +59,8 @@
    * be sure to call <code>super.close()</code> when overriding this
method.
    */
   @Override
-  public void close() throws IOException {
+  public void end() throws IOException {
+    super.end();
     if (input != null) {
       input.close();
       // LUCENE-2387: don't hold onto Reader after close, so


On Fri, Jun 14, 2013 at 8:13 AM, Benson Margulies <bi...@gmail.com>wrote:

> Since LUCENE-2145 is of specific practical interest to me, I'd like to
> pitch in.
>
> However, it raises a bit of a compatibility thicket.
>
> There are, I think, two rough approaches:
>
> 1) redefine close() on TokenStream to have the less surprising
> semantics of 'don't use this object after it has been closed', and
> change existing callers to close the reader for themselves, or provide
> a closeReader().
>
> 2) leave close() as is, and define, well, 'reallyCloseIMeanIt()'.
>
> I'm happy to do grunt work here, but I'm obviously not the person to
> decide which of these is appropriate and tasteful.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>