On Thu, Nov 27, 2014 at 3:27 PM, Michael Ströder <michael@stroeder.com> wrote:
Qian Li wrote:
> On Thu, Nov 27, 2014 at 4:51 AM, Michael Ströder <michael@stroeder.com>
> wrote:
>
>> Qian Li wrote:
>>> On Wed, Nov 26, 2014 at 5:30 PM, Michael Ströder <michael@stroeder.com>
>>> wrote:
>>>
>>>> Qian Li wrote:
>>>>> Recently, I tried to write a ldap client to do ldap search
>>>> asynchronously,
>>>>> but failed to perform search operation after a successful async sasl
>>>>> (digest-md5) bind.
>>>>
>>>> What's your use-case for having async bind operation?
>>>>
>>>> Note that the bind operation is somewhat special because it establishs a
>>>> security context/association.
>>>
>>> The ldap client is a daemon which accepts arbitrary request
>>> from outside
>>
>> What kind of requests?
>
> There are IPCs from other processes and the ldap client is only single
> thread.

I did something very similar recently.

>> I don't know what's your exact use-case. But if you're cautious about
>> performance you should open a connection pool of persistent connections and
>> always bind *once* during connection lifetime.
>
> Yes, persistent connections pool is another solution.
> The search operation works in both async simple bind and sync
> SASL/DIGEST-MD5 bind, but doesn't work in async SASL/DIGEST-MD5 bind. This
> confuses me...

You have to wait for the SASL bind to complete *before* sending the subsequent
search operation anyway => persistent connections are *the* solution.

I did wait for the async SASL bind to complete. Unfortunately, the search operation still didn't work.
I have to use sync SASL bind, like persistent connections pool.

 
In my case such a simple local demon served 300+ requests/second with the LDAP
server with debug log and the demon running on the same old laptop. One
request to the demon sends three synchronous LDAP requests.
 
In my case, every response from LDAP server may include many entries. Async search will be more efficient.

Thanks
-Qian