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
<[email protected]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
