tracker issue : CF-4203450

select a category, or use search below
(searches all categories and all time range)

ObjectLoad() Component Never Garbage Collects / ObjectLoad() = Memory Leak

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/CannotReproduce

Reporter/Name(from Bugbase): Dave DeVol / ()

Created: 11/09/2018

Components: Core Runtime, Performance

Versions: 2016

Failure Type: Memory Leak

Found In Build/Fixed In Build: 2016 /

Priority/Frequency: Normal / All users will encounter

Locale/System: ALL / Win 2016

Vote Count: 4

	setting requesttimeout=600;
	function testObjectLoadSave() {
		var itemCount = 1000;
		var thingMap = {};
		for (var i=0; i<itemCount; i++) {
			var thing = new thing();
			thing.setName("Thing " & i);
			thingMap[i] = ToBase64(ObjectSave(thing)); // what we store in Redis
		for (var i=0; i<itemCount; i++) {
			var cached = thingMap[i]; // what we get back from Redis
			var thing = ObjectLoad(ToBinary(cached)); // comment this out and it will not eat up memory
			// WriteDump(thing);
		// WriteDump(thingMap);
	start = GetTickCount();
	loopCount = 1000;
	for (i=0; i<loopCount; i++) {
	end = GetTickCount();



ObjectLoad() Component Never Garbage Collects / ObjectLoad() = Memory Leak Using ColdFusion 2016 Update 7. Running jdk1.8.0_172.We were caching components in ehCache (in-process) without any issues. We recently started using Redis for some of our caches. We were able to convert to Redis by saving serialized objects (queries, strings, structs, etc) and deserializing them. However; when we launched the first large project using components, it all worked (except our memory was climbing and climbing and never going down). I was able to determine it was something related to using ObjectLoad() on ObjectSave()ed components.
Comment by Dave D.
29918 | November 09, 2018 11:38:12 PM GMT
At this point, I'm pretty sure that the memory consumption is somehow caused by the implementation of CFCs. (I work with Dave. He is our CTO.) When I identified this problem earlier, I thought it was a problem with ObjectLoad(), specifically for components. I'm able to ObjectSave() and ObjectLoad() millions of strings and the JVM memory barely moves. I'm also able to just ObjectSave() (but not Load) millions of components. The problem happens when I ObjectLoad(cachedComponentBinary). Since we thought maybe it was ObjectLoad, I decided to look at how Java serializes and deserializes Java objects. I ended up writing a function called MyObjectLoad(). I have attached it to the issue. It does exactly what ObjectLoad() should do. I can serialize a query or component and turn it exactly back into a query or component. I did my tests again with that new function. The results were exactly the same. I was able to consume gigs of RAM in a short period of time. And it was never GCed. The documentation says ObjectLoad: > Loads a serialized ColdFusion array, *CFC*, DateTime object, Java object, query, or structure into memory as the corresponding object. We are using a feature as advertised. It is causing our servers to entirely run out of RAM.
Comment by Chris P.
29919 | November 10, 2018 03:31:56 AM GMT
Chris/Dave, I understand, the issue arises only when you use Redis with CF2016 update 7, for storing objects. CF2016 does have built-in support for Redis, but for storing session scoped variables only. And we have built-in support for Redis as an alternative caching engine to ehcache, but with CF2018 onwards. So it's not clear if you have some sort of custom mechanism for pluging in Redis for your caching with CF2016. I'd want to reproduce the issue at my end. Thanks for sharing the test CFML snippet. Can you also share some details on how you've implemented your alternate caching mechanism.
Comment by Piyush K.
30496 | March 13, 2019 04:39:28 PM GMT
Chris, I've tried running the attached test code on CF2016 u12 and CF2018 u7 (on win x64). I can see the memory used by CF process getting reclaimed by the OS. I am using the default CF caching ehCahce with CF's objectLoad and objectSave (not your custom objectLoad method). I'm closing this since it is not reproducible with a standard CF installation. If you'd like this to be investigated further, pls share the info requested in my previous comment. you can also write to me at, in case a comment here does not get you a timely response.
Comment by Piyush K.
33305 | March 16, 2020 07:33:55 AM GMT