Comments on: Memory-sensitive Caching for CF

By: John Allen

John Allen — Tue, 10 Jun 2008 00:56:13 +0000

DUDE! THIS SAVES MY DAY/MONTH!!!!
Thank you.
John Allen

By: Ashwin

Ashwin — Tue, 27 Mar 2007 09:58:50 +0000

Hendrik - softcache.cfc does not touch the data put into it at all, so you should be getting it back unchanged. I’m sorry, but I’m really not sure what the root of your particular problem might be.

By: Hendrik

Hendrik — Tue, 27 Mar 2007 09:35:39 +0000

By using the softcache.cfc, i’ve noticed the same behaviour of returning corrupted copies of large structures as with the duplicate() function before ColdFusion 7.02 with is fixed with the Cumulative Hot Fix 1 ( see http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb400074 ID #63910 ). Any clues? Or do i have to wddx the structure first to ensure that it’s correctly returned?

By: Ashwin

Ashwin — Thu, 22 Mar 2007 05:44:12 +0000

Jerad - thanks for pointing that out. Yet another victim of an abortive software upgrade attempt a couple of weeks ago! The link is fixed now.

By: hungry

hungry — Wed, 21 Mar 2007 21:35:34 +0000

the link to softcache.cfc seems to be down…is it still possible to get it?

thanks,
jerad

By: Mark Mandel

Mark Mandel — Fri, 16 Feb 2007 01:08:03 +0000

Ashwin -

Since the SoftReference is created inside a CFC, which is a singleton, I would then assume that it is for the classLoader that loads and handles that CFC (because a CFC is just another template, is it not?)

As long as the CFC is resident in a shared scope, the ClassLoader for it won’t be thrown away, I would have thought.

My issue was more actually that the SoftReference at the CF layer were being cleared, but the ones at the URLCLassLoader layer weren’t.

To get around this issue I’m simply creating one softReference for each object I want to let the JVM clear() as required, and passing that around my system. That was it doesn’t actually matter who/what clears() it - once it is cleared, nothing has a reference to it.

Ahhhh complex caching fun :oD

By: ashwin

ashwin — Thu, 15 Feb 2007 06:32:14 +0000

Hmmm… One thing to keep in mind, perhaps, is that your URLClassLoader is probably a child classloader to the classloader for the template on which it is used. When the template changes, the template’s classloader is thrown away (this is how CF handles hot deployment of templates, but that’s a subject for a blog entry, coming soon!), which may be another reason for the CFC SoftReference loaded by the URLClassLoader being thrown away, but not the one loaded by the CF classloader.

By: Mark Mandel

Mark Mandel — Thu, 15 Feb 2007 04:07:44 +0000

Actually Ashwin, I believe that my issue was caused by the fact I had some SoftReferences being created on my ColdFusion ClassLoader, and some being loaded on my URLClassLoader (JavaLoader to be exact), which I believe allowed the JVM to gc one set, but not the other.

Thanks for the great article.

By: Mark Mandel

Mark Mandel — Thu, 15 Feb 2007 02:07:35 +0000

Ashwin,

I based my caching layer in Transfer around soft references to help with memory management, but something very strange seems to be happening -

I have 2 soft references pointing to the same CFC, and it seems that one is getting collected, while the other one isn’t.

This doesn’t seem to make any sense, as if one is collected by the garbage collector, so should the other. I’m wondering if there is something to the nature of CFCs that would allow that?

Looking at my debug code as well, it almost seems to be that there is no strong reference between CFCs and any sub-CFCs they hold within them.

Any help there at all?

Mark

By: ashwin

ashwin — Thu, 01 Feb 2007 10:41:09 +0000

I haven’t tried it at all with the server monitor, Charlie. The results should be the same, since the server monitor uses the same JVM APIs to get overall JVM memory consumption data. The CF-specific memory tracking that the server monitor provides will not work with softcache.cfc, since the references to the CF objects are wrapped in Java SoftReference objects. CF memory tracking relies on being able to traverse a graph of CFML object references, estimating the memory consumed by each. Any Java objects are not tracked, since there is no way to determine the actual size of a Java object at runtime without turning on debugging on the JVM (requiring a server restart and a big performance hit), which we wanted to avoid.

Give it a go; if you have any issues, let me know, and I’ll be happy to work through them with you.