AsyncRequestID does not provide a useful async semantic

[chibenwa]

The asynchronous tooling in unboundId allows starting an asynchronous computation but to get it's result I am forced to get() it, which essentially forces to block until it completes. (JDK futures are typically falling into this pitfall, more expressive models like CompletabeFutures or Guava's Futures do not.)

This makes integration with non-blocking code really painfull. Eg reactor library.

A simple enhancement would be to add a system of callbacks enabling people to register actions to be performed upon receiving the response. I did a similar contributing on imapNio: yahoo/imapnio#118

Ultimately, this would allow me to refactor part of the James code and leverage non blocking code on top of the LDAP / authentication layers. Which could be a big win.

Would there be interest for this in the community?

[dirmgr]

Sorry for not getting to this earlier. However, I do believe that the LDAP SDK's asynchronous processing support already does what you're asking for.

For example, if you want to process an add operation asynchronously, then you can call LDAPConnection.asyncAdd(AddRequest,AsyncResultListener). If the provided AsyncResultListener is non-null, then when the LDAP SDK receives the response to the request, it will call the AsyncResultListener.ldapResultReceived method, and that's where you can do whatever processing you want for that result. You don't need to rely on the AsyncRequestID at all in that case (unless you want to abandon or cancel the operation).

This approach is available for add, compare, delete, modify, modify DN, and search operations. In the case of search operations, the search request needs to have been created with a constructor that uses a SearchResultListener, and that listener must be actually be an AsynchSearchResultListener, which provides methods that will be called for each entry and reference that is returned for the search, as well as for the final search done message.

We don't support asynchronous processing for for either bind or extended operations, and that is intentional. Bind operations must always be processed in isolation on a connection, so whenever a bind request is received on a connection, the server will stop working on any other operations in progress on that connection, and it won't allow any new requests on the connection until the bind is done. Similarly, some types of extended operations (for example, StartTLS) also need to be processed in isolation.