This thread was marked as having the correct answer, but I don't think we're done yet...
hitesh.patel1.1, you stated:
If your DIT (Directory Information Tree) structures contains 'ou' and/or 'cn' and if that is being search for, you will see this WARN as an informational msg which I can understand why it can be nuisance due to the volume and rate it is being written to the dsaname_warn_timestamp.log file.
I created several dozen session cookies over a few days and confirmed they were added to the session store using an LDAP browser. I then used the console to check the cache and have highlighted several items:
dsa> get cache;
get cache;
Cache enabled
cache-no-scan = FALSE
interrupt-searches = FALSE
dxgrid-queue = TRUE
use-rdn-index = FALSE
max-filter-norm-size(MB) = 100
cache-index =
objectClass dxDeleteTimestamp createTimestamp modifyTimestamp cn smTimeValue ou smSessionId smExpirationTime smIdleExpirationTime
cache-reverse = (none)
Counters: [ entries ( values search-hits) ]
objectClass(0): 32(9 1879)
dxDeleteTimestamp(5): 899(898 1)
createTimestamp(6): 15(14 8)
modifyTimestamp(7): 5(5 8)
cn(13): 6(6 0)
smTimeValue(19): 894(894 0)
ou(22): 1(1 0)
smSessionId(23): 13(13 0)
smExpirationTime(25): 6(6 0)
smIdleExpirationTime(26): 6(6 4)
Number of EIDs in use 914
Memory used by cache: 6464536 out of 6507518
(Memory initially used by data only: 1610032)
Memory leaked 0
Number of Cache Hits 34424
Number of Sequential Scans 0
Free lists:
EntryLists: 0
Constrained values: 244
Unconstrained values: 0
IndexList: 0
dxgrid-db-location = /apps/CA/Directory/dxserver/data
dxgrid-tx-location = /apps/CA/Directory/dxserver/data
dxgrid-backup-location = /apps/CA/Directory/dxserver/data
dxgrid-db-size = 4000000
Used bytes in file = 36572
Reclaimable bytes = 130
Total number of entries = 914
disable-transaction-log = true
disable-transaction-log-flush = true
dsa>
Note there are over 34,424 cache hits, but the only attribute with a significant number of search hits is objectClass. Attributes with search hits are highlighted in green. The items I added to get the warn log to calm down are highlighted in yellow, and there are NO cache hits for them. smSessionId and smExpirationTime also have no search hits, even though the documentataion recommends those objects be indexed.
HubertDennis suggested that 'search hits' are what make the cache useful. If that's true, then I see a disconnect between the fact that the warn log fills up with messages regarding ou, cn, and smTimeValue if those attributes aren't indexed, yet they appear to get no search hits if they are indexed. It seems to me that the code is writing messages to the log file when it can't find those attributes in cache. Wouldn't that constitute a search? Here are my questions:
- Is there any performance benefit (or performance hit?) to indexing ou, cn, and smTimeValue?
- Is the code actually searching for ou, cn, and smTimeValue but those searches and search hits are not being logged correctly?
- Is the code incorrectly writing messages to the warn log if those attributes are not indexed?
I'm pretty new to CA Directory and trying to understand which is worse: lots of useless, expected messages in the warn log, or possible overhead added by 3 addtional indexes that don't get any search hits.