Forum OpenACS Development: Problem with cache UI

Posted by Antonio Pisano on 04/08/14 05:15 PM

Hello,

I've stumbled in a problem while trying to look into cached keys on my development server. It comes from a cvs update two days ago.

An example page is /acs-admin/cache/show-util-memoize?pattern=util , that should return an error because the
proc looking for the keys doesn't return their timestamp anymore when called on Naviserver.

I've done some research and found there have been some big changes in caching system around september, and now cache on Naviserver is handled by a new native api.

Procs retrieving cache values on Naviserver behave differently from those defined on Aolserver. As I could see from comments in the code, this is something you are aware of.

What I ask is: is there already a plan about UI for the two servers? Is this going to fork? Why can't we just get the timestamp from the new api and mantain the same behavior?

2: Re: Problem with cache UI (response to 1)

Posted by Gustaf Neumann on 04/08/14 10:25 PM

Dear Antonio,

i guess, this slipped through, since this user interface is limited to the util_memoize cache only, and people use different interfaces. I've added compatibility for NaviServer (committed to the oacs-5-8 branch).

best regards
-g

3: Re: Problem with cache UI (response to 2)

Posted by Antonio Pisano on 04/08/14 11:22 PM

Oh, sorry Gustaf, I really thought util_memoize was THE api when talking about cache.

Is it still ok to use it, or you're going for a different preferrable idiom? If so, what is it?

4: Re: Problem with cache UI (response to 3)

Posted by Gustaf Neumann on 04/09/14 06:36 PM

Putting everything in a single cache (like the util_memoize cache) becomes a scalability issue, since there will be competition between all concurrent connection threads for obtaining information from there, since all accesses require mutex locks. especially bad are cases, where e.g. all keys are retrieved from a cache (this might be several a list with hundred thousand or more entries) in a huge list, and the list of keys is later processed for some patterns to for invalidation. Unfortunately is a not a seldom idiom in OpenACS + DotLRN. During the generation of this huge list the cache has to be locked, meaning that all other cache requests from other threads for the util_memoize cache have to wait. One can get statistics about that via nsstats.tcl.

That is one of the reasons, why e.g. xotcl-core/xowiki use different caches.

These locking problems show only up for large and busy sites, for small sites, this does not matter.