[
https://issues.apache.org/jira/browse/DIRSERVER-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681924#comment-16681924
]
Rajini Sivaram commented on DIRSERVER-2257:
-------------------------------------------
[~elecharny] Thank you for looking into this. Yes, if the listener can be set
up before doing the simple search and the changes are queued up, it would fix
this issue.
> Missing entry due to timing issue with persistent LDAP search
> -------------------------------------------------------------
>
> Key: DIRSERVER-2257
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2257
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 2.0.0.AM25
> Reporter: Rajini Sivaram
> Priority: Major
>
> LDAP search using {{PersistentSearchControl}} with {{changesOnly=false}} must
> return all existing entries followed by any changes so that the client sees
> all entries (https://tools.ietf.org/html/draft-ietf-ldapext-psearch-03). The
> current implementation processes all existing entries and then sets up a
> listener to process entry changes. This leaves a small timing window where
> entries created while the existing entries are being processed, but before
> the persistent listener is created are never returned to the client. We see
> intermittent test failures as a result of this timing window in tests which
> start a persistent search and create entries immediately after that.
> The relevant code is here:
> https://github.com/apache/directory-server/blob/master/protocol-ldap/src/main/java/org/apache/directory/server/ldap/handlers/request/SearchRequestHandler.java#L141
> It is hard to add a workaround for persistent search if all entries are not
> guaranteed to be returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
