[AOLSERVER] ns_cache key size

[Titi Alailima]

Digging deep into the ACS session properties, I discovered something disturbing: even though ns_cache holds as large a key as you want to give it, it will only uniquely identify according to the beginning of the key when setting.  In other words, the following code:

ns_log Notice "Sec properties: [ns_cache names util_memoize "sec_*"]"
ns_cache set util_memoize $script [list [ns_time] $value]
ns_log Notice "Sec properties: [ns_cache names util_memoize "sec_*"]"

Executed where $script evaluates to "sec_lookup_property 2304 general-editor upload_content" ($value is irrelevant) shows this in my log:

[14/May/2009:10:52:57][20497.4201664][-conn:bridge::2] Notice: Sec properties: {sec_lookup_property 2304 general-editor upload_file}
[14/May/2009:10:52:57][20497.4201664][-conn:bridge::2] Notice: Sec properties: {sec_lookup_property 2304 general-editor upload_content}

So an entry that was there under a different key has disappeared and is now replaced by an entry with the new key.  My only conclusion can be that ns_cache set assumed the two entries had the same key, although curiously it replaced the full value of the old key with the full value of the new key.  Also curious is that "ns_cache get" can still tell the difference between the two keys.

 

I found that Ns_CacheCreate takes in a parameter that specifies the size of the key, and it seems to use the value of TCL_STRING_KEYS, though I don't know where that value is set.  Is this the culprit, and if so how can I change this?  If this is not the culprit, what is?

 

Titi Ala'ilima

Lead Architect

MedTouch, LLC

1100 Massachusetts Avenue

Cambridge, MA 02138

617.621.8670 x309

Fax: 888.770.5082

--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.

[Titi Alailima]

Grrr... after broadening my search I discovered that the "ns_cache set" was wiping out all the other entries as well, so it was actually an issue of the size limitation for the cache itself.  I think I shall switch to using a separate time-limited cache for this purpose instead.

 

Sorry for wasting your time.

 

Titi Ala'ilima

Lead Architect

MedTouch, LLC

1100 Massachusetts Avenue

Cambridge, MA 02138

617.621.8670 x309

Fax: 888.770.5082