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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24801

Apache crashes when distinct users exceeds LDAPCacheEntries

           Summary: Apache crashes when distinct users exceeds
                    LDAPCacheEntries
           Product: Apache httpd-2.0
           Version: 2.0.47
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Major
          Priority: Other
         Component: mod_ldap
        AssignedTo: [email protected]
        ReportedBy: [EMAIL PROTECTED]


The following *is* true with Apache 2.0.47 on Windows.  It *may* well be true 
on other platforms as well -- I've not done sufficient testing to say for 
certain.

Apache crashes when the number of distinct users authenticating against LDAP 
exceeds the setting used for LDAPCacheEntries.  This does not always occur on 
first exceeding this cache size, but in my experience it will invariably occur 
after a few occurences of exceeding the cache size.

A little debugging strongly suggests that there is an issue with the code which 
removes old entries from the cache in this case.

The workaround is either to use a value of 0 for LDAPCacheEntries, i.e. disable 
the cache, or use a value that is larger than your user population plus some 
safety factor.  The safety factor is necessary in that it appears to be 
possible to have more than one entry for a given user in the cache.  This 
appears to occur when one request is using the user entry when another request 
for authenticating the same user comes in.

This issue is masked by bug #24800 and cannot be reached until you work around 
it.

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

Reply via email to