lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Ritchie <br...@jivesoftware.com>
Subject Re: RE : DateFilter.Before/After
Date Mon, 15 Sep 2003 14:47:20 GMT
Erik Hatcher wrote:

> On Monday, September 15, 2003, at 09:45  AM, Bruce Ritchie wrote:
> 
>> I would suggest *not* using caching inside of filters provided by 
>> lucene but rather provide a wrapper to do the caching. The reason is 
>> that some applications really don't want the libraries they use to be 
>> a source of concern for memory usage. i.e. if I search for a string 
>> using 10,000 different date filters (an extreme example, but possible) 
>> I want the ability to control how those bitsets are going to be > cached.
> 
> 
> In the case of QueryFilter, simply construct a new one to avoid caching 
> rather than reuse the same instance.  So you have control there as 
> well.  The only thing that is cached is a BitSet, so it should be much 
> of a memory usage concern.

Perhaps. I guess my point is that I would prefer a wrapper architecture for caching rather
that 
having it built-in directly in the filters. Having it built-in would require me to rip it
out when I 
upgraded our applications to the latest release. Implementing it as a wrapper allows me to
bypass 
the caching built-in and decide what I want cached, how many I want cached and for how long
(our 
caches can be size and time limited). Having it as a wrapper also allows other people to make
the 
same sort of decisions as I require.

>> public class CachedFilter extends Filter {
>>     BitSet bits;
>>     Filter filter;
>>
>>     public CachedFilter(Filter filter) {
>>         this.filter = filter;
>>         this.bits = null;
>>     }
>>
>>     public BitSet bits(IndexReader reader) throws IOException {
>>         if (bits != null) {
>>             return bits;
>>         }
>>
>>         bits = filter.bits(reader);
>>         return bits;
>>     }
>> }
> 
> 
> You would have problems if you searched a different index or different 
> instance of IndexReader even with your caching here.  You should cache 
> like QueryFilter does to avoid a potential mismatch with IndexReader 
> instances.

Well, there's a part of the application that you're not seeing that does the checking of the
index 
state. This is done inside of what is essentially a wrapper to a map which clears all filters
upon a 
state change in the index. Your point is perfectly valid however for anyone who does not have
such a 
wrapper and one that I should have mentioned in my previous email.


Regards,

Bruce Ritchie

Mime
View raw message