DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27748>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27748

ldap auth periodically fails, requires restart





------- Additional Comments From [EMAIL PROTECTED]  2004-05-24 20:43 -------
I repeated my test set-up that I'd been using under bug 27134, with the roll-up
patch 11618 from bug 27748. This was on Red Hat Linux 9.0, building Apache from
patched 2.0.49 sources (not Red Hat sources)

This uses two test data sets with 11 valid username/password pairs and some
pseudo-random failures. One data set walks through the usernames in nearly
serial order (because this will tend to show the worst-case usage of the
connection pool). This makes 103 requests. The other data set uses a more random
series of usernames. This makes 804 requests.

The results look good.

I'm now getting no unexpected authentication results, and socket usage looks
similar to Denis Gervalle's previous patch.

I still have the warning "LDAP cache: Unable to init 
Shared Cache: no file", but I suppose that's a different issue.

I did the tests first with the default settings of

StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients         150
MaxRequestsPerChild  0

For comparison, I set up a low process number test with:

StartServers         1
MinSpareServers      1
MaxSpareServers     1
MaxClients         150
MaxRequestsPerChild  0

and high process number test with:

StartServers         10
MinSpareServers      10
MaxSpareServers     20
MaxClients         150
MaxRequestsPerChild  0

All the tests give correct results (authentication works or fails as expected).

I looked at sockets in use with "netstat -an" on the LDAP server.

With the default prefork process config:
the serial data set left 9 sockets to the LDAP server in use at the end;
the random data set left 4 sockets in use at the end

With the "low process" config:
the serial data set left 1 socket in use at the end;
the random data set left 0 sockets in use at the end

With the "high process" config
the serial data set left 14 sockets in use at the end;
the random data set left 11 sockets in use at the end;

I'm guessing that if I could get rid of the "Unable to init 
Shared Cache" warning I'd get results more like the "low
process" config. Can anyone suggest another fix/bug that
applies to that issue?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to