[
https://issues.apache.org/jira/browse/DIRSERVER-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu closed DIRSERVER-677.
-----------------------------------
Resolution: Fixed
This is the case now after having moved to using Cursors after the bigbang
> Refactor interceptors so only one SearchRequestFilteringEnumeration is used
> ---------------------------------------------------------------------------
>
> Key: DIRSERVER-677
> URL: https://issues.apache.org/jira/browse/DIRSERVER-677
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.0-RC3, 1.0-RC2, 1.0-RC1, pre-1.0
> Reporter: Alex Karasulu
> Assignee: Alex Karasulu
> Priority: Trivial
> Fix For: 2.0.0
>
>
> We need to clean up the number of nested (wrappings of)
> SearchResultFilteringEnumerations. It's best if we relocate the code that
> wraps Partition specific Enumerations with this into the Nexus. There we can
> add Filters to a single SearchResultFilteringEnumeration. Right now a few
> interceptors wrap 3 layers of SearchResultFilteringEnumerations. Here are
> the offending interceptors:
> (1) DefaultAuthorizationService
> (2) SubentryService
> (3) CollectiveAttributeService
> Creating a new SearchResultFilteringEnumeration everytime costs us about 2%
> total of processing time in search operations. We could save a total of 4%
> and improve the code.
> Regarding addFilter usage
> ------------------------------------------
> Note that some interceptors, these 3, need to add filters at searh
> construction time rather than at interceptor service init time. These
> services can use the addFilter() interface of the
> SearchResultFilteringEnumeration but this interface must make sure the first
> prefetched entry is evaluated otherwise the first entry will be returned even
> if your filter rejects it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
