[OPENDJ-3868] Proxied persistent searches are not cancelled/abandoned when the client abandons them or disconnects Created: 15/Mar/17  Updated: 08/Nov/19  Resolved: 25/Sep/17

Status: Done
Project: OpenDJ
Component/s: proxy
Affects Version/s: 4.0.0
Fix Version/s: 5.5.0

Type: Bug Priority: Critical
Reporter: Matthew Swift Assignee: Yannick Lecaillez
Resolution: Fixed Votes: 0
Labels: Verified, release-notes

Issue Links:
is required by OPENDJ-3707 PersistentSearchControlTest#testMaxPS... Done
relates to OPENDJ-3654 The proxy should support end-to-end b... Done
is related to OPENDJ-3711 Cancellation of requests should be mo... Done
QA Assignee: Viktor Nawrath [X] (Inactive)


Our commons Promise API does not support cancellation chaining. Since the LDAP client SDK returns chained promises it is not possible to abandon/cancel a request via the promise's cancel() method.

The implication is that long running proxied operations, such as persistent searches, are never cancelled, even if the associated client disconnects, since the life-cycle of frontend connections is decoupled from the life-cycle of backend connections.

As a workaround we may want to consider implementing special handling for persistent searches, e.g. by allocating a non load-balanced specialized connection for each psearch in order to avoid promise chaining used by request based load-balancers.

In the long term, we should migrate the LDAP SDK client APIs to RxJava (OPENDJ-3654) where chained cancellation is supported, as well as the back-pressure support which we also need for a scalable proxy.

Comment by Matthew Swift [ 25/Sep/17 ]

What is the status of this issue? It must be completed for 5.5.0.

Comment by Matthew Swift [ 25/Sep/17 ]

Christophe Sovant / Viktor Nawrath [X] - Yannick is waiting confirmation of the test results, before marking this issue as resolved.

Do you have any feedback?

Comment by Viktor Nawrath [X] (Inactive) [ 09/Oct/17 ]

Verified with OpenDJ 5.5.0-SNAPSHOT rev.: a6e372c95ff

Generated at Fri Sep 25 13:39:27 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.