[
https://issues.apache.org/jira/browse/DIRSERVER-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681294#comment-16681294
]
Emmanuel Lecharny commented on DIRSERVER-2257:
----------------------------------------------
You are correct.
The idea could be to set the listener *before* doing the search, but to only
enable it when the search is completed. Every change would be queued up to the
moment the simpl search is completed.
This is not necessarily complex to implement.
> 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)
