I almost included this in with the last E-mail, but I figured I’d start a different thread. I’ve seen this error about 3 or 4 times since we went to production with RC1:
Element DETAIL is undefined in E.
Line 47
\coldbox\system\cache\policies\LRU.cfc
We’re using the default store which I think is the concurrentSoftReferenceStore. I’m wondering if a Java exception is being thrown from one of the Java classes in use. Java Exceptions don’t always behave the same as a cfcatch struct.
The error never happened on dev or stage, but unfortunately we don’t do any load testing so concurrency issues don’t always show up until you get traffic happening.
If it keeps happening regularly, I might go add in some additional error catching to try and figure out what the exception looks like. Actually, let me go check my “out” logs… nope, nothing there.
The first part of the answer is that on RC1, you are referencing the
non-existant oCacheManager.expireKey method in the processEvictions
method of AbstractEvictionPolicy. This method appears to now be
expireObject. The error is try/caught and logged, but not rethrown.
That means my eviction policy has been silently erroring. I also
noticed that I wasn't using the correct config for cacheBox so my
maxObjects setting wasn't in use and my ColdBox cache has been maxing
out which fires your eviction policy on every "set". That means it's
been erroring a lot.
The second part of the answer is that I believe I have found a bug in
ColdFusion 8 (minimally) where the "catch" error struct is not locally
varred the first time a component is called concurrently and multiple
threads causing an error simultaneously will overwrite each others
catch struct the first time. (It only happens once until you reinit
again) It is a very peculiar error, but I created a test that
reproduces the problem every time. (Blog entry coming later).
So, there's nothing we can do about a CF bug (other than log it and
vote for it), but what we need to do for ColdBox is ensure we fix the
expireKey calls (if not already fixed on the nightly). I'm guessing
that given the infrequency that errors generally happen in the
framework have always kept the try/catch race condition window small
enough to not notice it. That, and the fact that the behavior can
only be produced once per the life of an object. (I'll try to explain
more in my blog post)