I set up a generic instance of 1.4.1, with only a few sample entries in the database, but after doing a few operations the NDN cache count is very high (much higher than worker threads * number of entries). So either the count if off, or we are adding duplicate DN's to each thread's NDN cache.
Metadata Update from @mreynolds: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4.2
Every thread has it's own NDN cache, so they may end up with duplicate numbers yes. As well the counter is asynchronously updated in the threads so I think this is not a bug - it's an 'estimate' not accurate.
Well I can't reproduce the large growth. But once I did see the count was at 2003 dn's in the cache, but there was only 19 entries in that db. So 24 worker threads * 19 entries is 456. So 2003 is a big difference. Was the counter off, or were we actually storing multiple DNs in the each thread's cache and wasting memory? Hard to say since I can't reproduce it.
I'm going to close this issue, and if I see it again I'll reopen it.
Metadata Update from @mreynolds: - Issue close_status updated to: worksforme - Issue status updated to: Closed (was: Open)
It's a count of the un-normalised inputs -> normalised forms, so 24 works * 19 entries * 4 different capitalisations of those (IE CN=Mark, cn=Mark, cn=mark, Cn=Mark, CN=mark). would quickly approach 2000 ish.
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/3573
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: worksforme)
Login to comment on this ticket.