cbCsrf module - token reset

just hit button again after 5 mins and the cbstorage key IS in the panel… but the token again changed:

after 5mins:

Ok, I have replicated this. I think the reaping is the issue in CacheBox. I will have to keep investigating. Very tricky to replicate.

Oh good (not good that there’s a problem, but good that I am not going crazy!)

I have found the issue @Andrew_Kretzer . You have won the prize of one of the most convoluted bugs every! LOL!

It actually is a pretty serious bug and it’s on CacheBox. basically the issue is that the reap looks at several criteria to determine what cache items to evict from the caches. It looks at expirations, soft references, timeouts, and last access timeouts.

However, last access timeouts are ONLY supposed to be used if > 0. If you use 0, it means, don’t use a last access timeout. Well, this was being ignored. So any item in the cache with a 0 last access, woud have been reaped out of the cache every time the cache reaped, which the default is, wait for it… 5 minutes.

Ok, fixing a patch in ColdBox right now.

As a workaround, disable last access timeouts at the cache provider level:

// Named cache for all coldbox event and view template caching
template : {
	provider   : "coldbox.system.cache.providers.CacheBoxColdBoxProvider",
	properties : {
		objectDefaultTimeout           : 120,
		objectDefaultLastAccessTimeout : 30,
		useLastAccessTimeouts          : false,
		reapFrequency                  : 5,
		freeMemoryPercentageThreshold  : 0,
		evictionPolicy                 : "LRU",
		evictCount                     : 2,
		maxObjects                     : 300,
		objectStore                    : "ConcurrentStore" // memory sensitive
	}
}
2 Likes

Here is the ticket: [CACHEBOX-75] reap operation was not ignoring 0 values for last access timeouts - Welcome
It is resolved now and working. The new build will be be. Once we have more tickets closed on ColdBox we can do a minor release.

Terrific - thank you Luis and Brad!