Another thing to check for is if the heap eventually goes down overnight as sessions time out. Could be scope-widening injection keeping the framework/models in memory. Heap analysis tools like Jrockit mission control our IBM MAT can be super-useful though a bit of a learning curve for CF people. Railo has a memory monitor extension, but the trial date has passed and I don’t think they ever updated it 
Thank you Brad,
Question: What would be your primary list to check up in Coldbox and maybe server when launching a site that is expecting to have lots of visits, carts, database updates, etc?
Thanks Again
Xerrano
Sorry, not sure I completely understood that question. It sounds like you’re asking for a checklist of things to consider when rolling out a site like that?
Firstly, as far as the scope-widening injection-- the rule of thumb is when injecting a direct reference of an object (A) into another object (B), ensure A has a scope (or life span) that is greater or equal than B. Most people think that singletons have the longest scope of any component, but this this is not true since singletons die on reinit, which can span session and/or application scope.
Consider the following:
user.cfc
component scope=“session” {
property name=“coldboxController” inject=“coldbox”;
}
This CFC will be placed in the session scope and have a hard reference to the ColdBox Controller placed inside it. This controller, in turn, has references to pretty much every other CFC in the framework-- WireBox, CacheBox (and any in-memory cache stores), LogBox, Request Service, handler service, etc. Now, you reinit the framework and the entire framework gets created over again, yet our user object still lives on in session holding a reference to the original framework. There are now two full copies of the framework in memory, and the first one can’t get garbage-collected until the user object times out of session.
The way around such issues are to not inject hard references, but use a provider which is a place holder object that will go and get your dependencies when you need them so no hard references exist in the heap.
user.cfc
component scope=“session” {
// Provider only works on DSLs in later versions of WireBox
property name=“coldboxController” inject="**provider:**coldbox";
}
My other bit of advice is to load test your application with real-user traffic before ever going live so you can do proper memory and JVM tuning before you hit production.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Don’t use fwreinit in production… If you have too, use it sparingly…
But what is you real question here.
Thank you guys,
I think you got me right, your answers showed me a good track to go and double check a few things.
Brad: You got my attention about the “provider” is there some docs or samples on how to use this concept?
Andrew: What happen by using fwreinit in production? if I replace new models or objects, how in that case make Coldbox to updateand replace the old ones?
Thank you guys again
Xerrano
It is more that you have seen one side affect to it, but the other side affect is that any fwreinit will ALWAYS affect any user on the system at the moment. Yes, if you schedule your maintenance and the site is down and not being used at this time, then there would be no issue.
I don’t need to add any more as Brad has covered the rest.
ok got it!.. Thanks Andrew! 