On Thu, Nov 27, 2014 at 3:27 PM, Michael Ströder <[email protected]>
wrote:

> Qian Li wrote:
> > On Thu, Nov 27, 2014 at 4:51 AM, Michael Ströder <[email protected]>
> > wrote:
> >
> >> Qian Li wrote:
> >>> On Wed, Nov 26, 2014 at 5:30 PM, Michael Ströder <[email protected]
> >
> >>> 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

Reply via email to