But Mike you’ve contended all along that this was not the case for you. If perhaps you ended up writing another entry about all this, can you point to it here, so readers can find it? Or if you never solved it, but perhaps it went away when you moved to CF8 (or something else changed), please do tell. :-) I’m sure many readers (for years) will look forward to the understanding shared here.

In your examples you use Application scope for your CFC. a CFC in application scope will always be maintained so by adding 100 instances of itself to an ongoing array will always increase. Unless I am missing something it seems to me that it works exactly as you coded. 100 instances are created per request and stored in the array in the cfc. this adds exactly as you show it in the #instances.

Keep in mind that the 100 instances of the cfc are created within the VAR scope of the method that is being called. These variables are scoped locally to the cffunction, and not part of the component’s scope. Any variables within the var scope should only live for the lifetime of the method call.

The solution I found is to store all complex objects in server scope rather in Application scope or sesssion scope.

@Hemant did you test mentioned scenarios.

my suggestion is to store all complex object in server scope and you will see there is no memory leakage problem.

I am happy to help anybody who is struggling like these issues.

Thanks
Sana

http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb401239

This should fix the problem.

Thanks,
Hemant

http://www.jmpj.net/jason/index.cfm/2007/4/14/Cold-Fusion-Memory-Leak

Persisting large objects, i.e. queries nested in a structure does not necessarily cause a memory leak. It just takes up large amounts of memory for each active user of your system. I limit the use of session for this very reason. I once witnessed an application that cached much of the database in session (YIKES, poor design). With every new session I would see 4 meg peel off the server. Not a memory leak just poor design. Hope this helps.

We think actually we might just have found the leak.

Thanks to your tips we got JRockit running and ran a test against our app. There were thousands of instances of coldfusion.sql.* classes.

I immediately thought that the query of queries we use may be the issue so we wrote a little app that did the following:

1/ Create a component in the application scope with some methods to do query of queries on a structure of queries passed into it.

2/ Create an Structure with several keys, all different queries, and persist it in the session scope.

3/ Pass the structure as an argument to the methods of the component.

4/ Load test the app.

CF leaks like a rusty bucket.

Rewriting our app as we speak. Many thanks for all your tips.

Tom

I’ve had quite a few responses to my page at

http://www.digitalmethod.co.uk/cf

all from people with the same problem.

I have 4 servers running ColdFusion, one of which has been running for months without a restart and one of which needs a restart every 12 hours.

The only difference is the amount of load they’re under. Are you sure in your stress tests that you have simultaneous threads running, and that the server is at its limits?

I’m almost certain that there’s a memory leak in CF pertaining to components, and I think it happens when simultaneous requests call the same method of a component in the application scope using a session scope variable as an argument, something like:

application.objUser.fnCheckLogin(session.sUser)

where objUser would be a component and session.sUser is a Struct in the session scope.

A good test would be to create a function that uses all the suspected functions – CreateUUID(), hash(), arrayAppend(), StructCopy(), etc and call it with a session struct as an argument.

Having said that this issue does seem to be only affecting Windows users so the problem may be completely unrelated!

Tom

I’m still not quite sure why Robi was not able to recreate the issue in his local environment. A few months ago I tried running with Robi’s suggested jvm.config and jrun.xml and was still able to reproduce the behavior. In fact, I have now been able to reproduce on almost every combination of the following environments. (and verify that code changes fix the behavior)

CFMX: 6.1, 7.01, 7.02
JVM: Sun 1.4, Sun 1.5, BEA 1.4, BEA 1.5
OS: Windows Server 2003, Windows XP
(I have also tested a completely clean CFMX 7.02 install on WinServer 2003, with nothing else on the machine)

I know that Robi still doesn’t think that there is an issue with code, and believes it is related to environment, but I see a flaw in the test logic. When testing, in order to verify a fix I would follow these rules.

1. Reproduce the behavior
2. Make a Change to one variable in the equation (code, environment, etc)
3. Does behavior still exist? If yes, revert change and try another
4. Continue testing one variable at a time until behavior no longer exists

In Robi’s case, he was NEVER able to complete step 1, which means his testing really doesn’t tell us anything at all. The problem could be related to environment OR code, but there is NO way to tell with his tests.

In my case, I was able to demonstrate the behavior, then ONLY make a change to code and verify that the behavior was fixed. There is still a potential for an environment workaround, but I wasn’t able to find one. Until someone can reproduce the problem, make a tweak to the environment, and verify that the problem no longer exists, I don’t think that anyone can claim it is strictly an environment issue.

One additional note I would like to clarify is that we are talking about "Variables" scope here, NOT Var scope which Robi mentioned above.