[ 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)