public class JiraLuceneFieldCache
- extends Object
To paraphrase the Sex Pistols .... "THIS IS NOT A CACHE SONG".
Q. When is a class with the word Cache in it not a CACHE?
A. When it doesnt cache anything.
Oririnally this cached stuff but it was found that it consumed a hell of a lot of memory
for no benefit (JRA-10111). So the cache.put is never called.
The code for the getCustom() method is taken from Lucence in Action page 198 and as it states on
page 199 Lucence takes the results of SortComparatorSource (which this class helps build) and
... wait for it... caches them.
BUT the synchronise calls are still being made and hence JIRA is not as fast as it could be. After each re-index
we have a possible contention spot (for each different type of field). Its lucky
Lucene caches this output or it might be really slow.
This has all the hallmarks for REFACTORING.
The getCustom() method is still needed, its builds the sorted list of document field values. Its just that
it doesnt and SHOULD NOT cache them.
To quote Dylan (Etkin that is, not Bob) .. "this is &^%^%^! Please make it better."
|Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
public static final JiraLuceneFieldCache FIELD_CACHE
public Object getCustom(org.apache.lucene.index.IndexReader reader,
public Collection getMatches(org.apache.lucene.index.IndexReader reader,
- Return a BitSet that contains 'true' for every document that
Copyright © 2002-2008 Atlassian. All Rights Reserved.