lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3089) CachingTokenFilter can cause close() to be called twice.
Date Mon, 14 Nov 2011 11:32:51 GMT


Robert Muir commented on LUCENE-3089:

I just don't think it should be blanket policy without thinking things thru.

for example: lots of code you see on the internet opens a new indexreader for every search
and closes it

should we seriously encourage this?! If someone seriously needs to do this, thats an expert
case and
they can use try + finally and close themselves.

So for example, there I think it makes sense for IndexReader to not support AutoCLoseable,
and separately
to remove the stupid IndexSearcher(Directory) so that IndexSearcher only takes IndexReader,
so its *always*
a thin wrapper like we claim it is (which is an outright lie today). Then IndexSearcher would
implement [Auto]Closeable
since its cheap.
> CachingTokenFilter can cause close() to be called twice.
> --------------------------------------------------------
>                 Key: LUCENE-3089
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Robert Muir
> In LUCENE-3064, we added some state and checks to MockTokenizer to validate that consumers
> are properly using the tokenstream workflow (described here:
> One problem I noticed in TestTermVectorsWriter.testEndOffsetPositionWithCachingTokenFilter
is that providing a CachingTOkenFilter directly will result
> in close() being called twice on the underlying tokenstream... this seems wrong.
> Some ideas to fix this could be:
> # CachingTokenFilter overrides close() and we document that you must close the underlying
stream yourself. I think this is what the queryparser does anyway.
> # CachingTokenFilter does something tricky to ensure it only closes the underlying stream

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message