jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christoph Kiehl (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-974) Manage Lucene FieldCaches per index segment
Date Wed, 20 Jun 2007 16:47:26 GMT

     [ https://issues.apache.org/jira/browse/JCR-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christoph Kiehl updated JCR-974:
--------------------------------

    Attachment: patch2.txt

This is a revised version of the first patch. The following changes were applied:

- Using MultiIndexReader interface instead of providing own methods on CombinedIndexReader
and CachingMultiReader. This is not only better design but also improves performance a bit.
- Create caches proactive instead of lazily and use an array to access them. This improves
performance a little bit for successive queries.

> Manage Lucene FieldCaches per index segment
> -------------------------------------------
>
>                 Key: JCR-974
>                 URL: https://issues.apache.org/jira/browse/JCR-974
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: query
>    Affects Versions: 1.3
>            Reporter: Christoph Kiehl
>         Attachments: ItemStateManagerBasedSortComparator.patch, patch.txt, patch2.txt
>
>
> Jackrabbit uses an IndexSearcher which searches on a single IndexReader which is most
likely to be an instance of CachingMultiReader. On every search that does sorting or range
queries a FieldCache is populated and associated with this instance of a CachingMultiReader.
On successive queries which operate on this CachingMultiReader you will get a tremendous speedup
for queries which can reuse  those associated FieldCache instances.
> The problem is that Jackrabbit creates a new CachingMultiReader _everytime_ one of the
underlying indexes are modified. This means if you just change _one_ item in the repository
you will need to rebuild all those FieldCaches because the existing FieldCaches are associated
with the old instance of CachingMultiReader.
> This does not only lead to slow search response times for queries which contains range
queries or are sorted by a field but also leads to massive memory consumption (depending on
the size of your indexes) because there might be multiple instances of CachingMultiReaders
in use if you have a scenario where a lot of queries and item modifications are executed concurrently.
> The goal is to keep those FieldCaches as long as possible.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message