On 17/5/05 10:18, Eric A. Hall <[EMAIL PROTECTED]> wrote:
>
> What's the recommended method for testing to see if a search has produced
> any results?
>
> I've got a strange problem and I'm pretty certain that there's some kind
> of synchronization issue between my search and reads.
>
> In more detail and for background information, I'm working on an
> LDAP-based blacklist plugin for SpamAssassin. By default, the plugin runs
> in a non-persistent mode, such that new LDAP sessions are established for
> each incoming message, queries are run, and the session is destroyed. This
> all seems to work pretty well, but its a lot of sessions to deal with.
>
> For efficiency I am trying to get the processes to run in persistent mode,
> so that a daemonized instance of SA can reuse a single LDAP session for
> the lifetime of that process (each instance of SA gets its own session).
> This seems to work for a little while, but eventually it develops a
> timeout condition where the LDAP search results don't get caught, so the
> plugin hangs which causes a cascade of timeout-related problems. My
> current (development) code has:
>
> #
> # issue the LDAP search
> #
> $permsgstatus->{ldap_search_result} = $self->{ldap_session}->search(
> base => $self->{ldap_search_base},
> filter => $permsgstatus->{ldap_search_filter},
> scope => $self->{ldap_search_scope},
> deref => $self->{ldap_search_deref},
> timelimit => $self->{ldap_timeout},
> attrs => [$permsgstatus->{ldap_resource_attr}]);
>
> #
> # see if there was a problem
> #
> if ((! defined $permsgstatus->{ldap_search_result}) ||
The search method will generally only return undef if it couldn't send the
operation to the server.
> ($permsgstatus->{ldap_search_result}->error ne "Success")) {
The Message class's error method will block until the search completes. It
looks like it'll return some text returned by the server, which is *not*
useful to test.
Aside: LDAP servers return several bits of info in operation results. One is
the result code (an integer) which describes the precise outcome of the
operation. There's also a text field which can be used by servers for
returning some bit of free text. This text field doesn't contain anything
that should be tested by a program, as the contents of it aren't defined.
So I'd test the value of the code method instead, as this will return a
portable LDAP error number. (0 is OK)
>
> #
> # report the error if it's defined
> #
> if (defined $permsgstatus->{ldap_search_result}) {
>
> dbg ("ldapBlacklist\: search failed with \"" .
> $permsgstatus->{ldap_search_result}->error . "\"");
> }
>
> #
> # disconnect the session politely
> #
> dbg ("ldapBlacklist\: unable to proceed " .
> "... terminating");
>
> $self->destroy_ldap_session($permsgstatus);
>
> #
> # kill the module so that nothing more happens
> #
> die;
> }
>
> I'm not getting any hits on this when persistency is enabled and when a
> failure occurs. I checked the LDAP logs and the queries are definitely
> getting processed, so my guess here is that I'm running into some kind of
> synchronization problem and I need to wait for the query to be answered or
> errored as appropriate.
Your server could indeed be quite broken, but I'd go and check result codes
properly and see what changes that makes.
Cheers,
Chris
