jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Inefficient/useless UUIDDocId cache ( was : Search performance : MultiIndex)
Date Mon, 12 Nov 2007 10:18:16 GMT
Hi Ard,

excellent work!

Ard Schrijvers wrote:
>> Christoph Kiehl wrote:
>> Very nice analysis! It's indeed a very tricky bug ;) 
>> UUIDDocId should not use WeakReferences on the one hand and 
>> equals() on the other hand. 
>> Maybe we should better return the same instance of a 
>> CombinedIndexReader in SearchIndex.getIndexReader() if 
>> possible and use a "==" comparison in UUIDDocId instead? 
> Yes, this is IMO the best solution. We could have a static HashMap with
> key-value pairs workspacename-combinedIndexReader, and in
> SearchIndex.getIndexReader() return the combinedIndexReader from the
> static hashmap, and on changing an index, clear the combinedIndexReader
> from the hashmap. But, perhaps somebody has a much neater solution..?
> :-)

caching the combined index reader works as long as there are no changes, but 
that is rarely the case. things in a workspace will change frequently, which 
means with every change the UUIDDocId must be recalculated.

instead of keeping a reference to the combined index reader the UUIDDocId should 
rather keep a reference to the reader of the index segment, which returned the 
document number for the uuid. with this change the document number does not have 
to be recalculated just because the combined index reader changed.

>> But 
>> that's just a quick guess. Unfortunately I hadn't the time to 
>> really dig into it and I'm out of town until Wednesday. But 
>> maybe Marcel could comment on this?
> Also, I want to change the DocId.UUIDDocId String uuid into storing only
> 2 long's, the lsb and msb, since when re-using a combinedIndexReader
> instance, the number of UUIDDocId can grow very large, implying quite a
> bit more memory use. 
> WDOT? Shall I create two seperate JIRA issues for it, or just a single
> one? 

Please create two separate issues. We can get rid of the uuid string independent 
  of the other changes/optimizations.


View raw message