lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: ThreadLocal leak (was Re: Leaking org.apache.lucene.index.* objects)
Date Tue, 19 Dec 2006 22:50:03 GMT

: > What do you think about that alternative approach I mentioned?  Instead of having FieldCacheImpl
be aware of all IndexReaders, have FieldCache be an inst var in IndexReader?
: I wonder why it wasn't done that way to start with.... perhaps to
: completely separate sorting from index reading.  Anyway, it's not
: backward compatible, and it doesn't buy us much to change now does it?
:  We would get rid of a singe hash lookup on the reader, which is
: insignificant compared to anything the FieldCache is used for anyway.

the discussion on this i'm remembering was here...

Doron speculated that the reason FieldCache was seperate from IndexReader
was to keep the "caching" at a higher level then the "reading", i
suggested that if we're going to change the API, we should move the
"refrence" to the cache up into the Searcher since that's the place
Sorting is acctually done, but that it should still be based on weak ref
to the reader since multiple searchers might share a reader.

thinking about it now however, i would think it does make sense for the
IndexReader to hang on to it's field cache ... it would not only simplify
things a lot, and allow an IndexReader to explicilty "clear" it's cache
when it's closed, but it would also allow us to intellegently populate the
cache based on the individual segments in a MultiReader (so if some of hte
segments haven't hcange,d we don't reread that part of hte cache)


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

View raw message