Brad Nicholes wrote:
It appears to me that if it doesn't handle low memory situations or it is giving false positives, those are separate issues from pools vs. calloc/free. I still think we need to implement some better monitoring or logging code in the cache_mgr and enhance the cache-status pages so that we can track things like false positives. Maybe tracking the entries by user name and authentication state rather than just the number entries and how often the cache was hit.
This is a definite plan.
Maybe the real problem is with the locking. In fact just taking a quick scan through the code again, I am seeing something that bothers me in util_ldap_cache_comparedn()
if (curl) { /* compare successful - add to the compare cache */ LDAP_CACHE_RDLOCK(); newnode.reqdn = (char *)reqdn; newnode.dn = (char *)dn; util_ald_cache_insert(curl->dn_compare_cache, &newnode); LDAP_CACHE_UNLOCK(); }
It appears to be acquiring a read lock but then inserts a new node into the cache. Shouldn't it be acquiring a write lock before doing an insert?
I would say it does.
Another thing I noticed was that it didn't seem to handle the case when it was half way through adding something to the cache, and the attempt to do so failed. I plan to look at the code again in the next day or two to see if I can better figure out what it is doing.
Regards, Graham --
