Ok, so I think I have an answer on this.
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)
Thanks!
~Brad
On Jan 11, 5:28 pm, Luis Majano <
lmaj...@gmail.com> wrote:
> yea that is weird, it is supposed to be guaranteed as per the cf docs, so weird
>