[coldbox-3.8.1] Multiple CB applications on same server sharing same Coldbox core?

Rather than have multiple copies of the same downloaded ColdBox version on a single server, I thought I’d keep them in a central location to be shared among many CB applications. I’m having issues though which seem somehow related to caching (Save Class Files and Component Cache) on ColdFusion Server 9.0.1 running on IIS. When creating additional CB applications I receive a variety of strange errors, usually starting with this one: Error in instantiating the cfc model.ORMEventHandler but I get others as well at other times and I can’t seem to nail down exactly what is wrong.

If I remove all the Saved Class Files and restart the server then usually the first app I try works fine. Then the second and other others exhibit strange behavior. I’m using unique this.name values (see Application.cfc below). If I turn off Save Class Files all together then I don’t seem to have the problem any more. I understand that on dev boxes Save Class Files should be disabled, however, it is enabled on our production server (and will remain so) and I need to know how to set all this up to best avoid headaches as I promote my code to production.

I’ve found a couple helpful discussions but just can’t seem to piece the puzzle together:

  1. Is there a recommended filesystem structure for this situation? I’m fine with moving them out of the webroot, and honestly at this point I’d also be fine placing a complete copy of Coldbox in each App directory as well if it will solve the problems.
  2. Is there an advantage to using a CF Admin mapping vs app-specific? I’m just trying to keep life as simple as possible…and if Save Class Files is going to be enabled on the production server what is my best approach here?
    Thanks CB community!

My (mostly futile) attempts have been attempting this structure:

  • webroot/
  • org/
  • coldbox/
  • coldbox_3.8.0/
  • system/
  • core/ … etc
  • coldbox_3.8.1/
  • App1/
  • config/
  • Coldbox.cfc
  • handlers/
  • includes/
  • layouts/
  • model/
  • views/
  • Application.cfc
  • App2/

  • App3

  • App4

Then using the bootstrap method with application-specific mappings:

Application.cfc
`
component output=“false”{

// Application properties
this.name = “App1” & hash(getCurrentTemplatePath());
this.sessionManagement = true;
this.sessionTimeout = createTimeSpan(0,0,30,0);
this.setClientCookies = true;

this.mappings[’/coldbox’] = expandPath(’/org/coldbox/coldbox_3.8.1’);
this.mappings[’/includes’] = GetDirectoryFromPath( GetBaseTemplatePath() ) & “includes”;
this.mappings[’/images’] = this.mappings[’/includes’] & “\images”;
this.mappings[’/javascript’] = this.mappings[’/includes’] & “\javascript”;
this.mappings[’/styles’] = this.mappings[’/includes’] & “\styles”;
this.mappings[’/templates’] = this.mappings[’/includes’] & “\templates”;

// Mappings Imports
import coldbox.system.*;

// COLDBOX STATIC PROPERTY, DO NOT CHANGE UNLESS THIS IS NOT THE ROOT OF YOUR COLDBOX APP
COLDBOX_APP_ROOT_PATH = getDirectoryFromPath(getCurrentTemplatePath());
// The web server mapping to this application. Used for remote purposes or static purposes
COLDBOX_APP_MAPPING = “”;
// COLDBOX PROPERTIES
COLDBOX_CONFIG_FILE = “”;
// COLDBOX APPLICATION KEY OVERRIDE
COLDBOX_APP_KEY = “”;

// ORM Settings
this.mappings["/model"] = GetDirectoryFromPath( GetBaseTemplatePath() ) & “model”;
this.ormEnabled = true;
this.datasource = “dsApp1”;
this.ormSettings = {
cfclocation = “model”,
dbcreate = “none”,
dialect = “MicrosoftSQLServer”,
schema = “app1”,
logSQL = true,
flushAtRequestEnd = false,
eventHandling = true,
eventHandler = “model.ORMEventHandler”
};

…etc
}
`

Your answer is in the text of your problem.

If I turn off Save Class Files all together then I don’t seem to have the problem any more

That is correct, you MUST do that if you re going to be sharing code across Applications.

Thanks, Andrew, I really appreciate the quick response! So, as long as Save Class Files is enabled I’m going to have unavoidable problems when multiple CB applications are loading the same Coldbox core libraries from a central directory?

Even if:

  1. The central Coldbox libraries are outside the webroot or in any other standalone location separate from an actual application.
  2. I use CFAdmin mappings or per-application mappings
    Please pardon the seemingly superfluous questions, but I need to concretely know that this can’t be done so I can move on to another solution. As long as my brain thinks I can hack something together it won’t let me rest :slight_smile:

Finally, if Save Class Files being enabled is a setting I cannot change, then my options are limited to what exactly? To having a separate copy of the Coldbox libraries for each CB application, right? I’d imagine it’s still preferable to store these outside the webroot…maybe I could use something like Brad’s example here to keep a separate libs/ directory for each app?

I appreciate your help tremendously!

Wes

No we need to clarify something.

If you have save files set in the CF Administrator, all ColdFusion applications that share any common code is going to have issues, this is not just a ColdBox issue.

Unless you are going to be setting up a server for one Application only, it is Highly recommended to always switch this caching etc off in the Administrator. As far as not being able to change, I think that is mute when you understand the reason why those settings exist. They are there to help speed up single Application per instance of ColdFusion, in a real world that doesn’t happen as much as you might think.

Also with Coldbox conventions, you can easily leave the code in the webroot. Because it is by convention, you can just change the convention names and it would make it hard to guess. Provided you follow best practices, I see no issues at all leaving code in the web root.

MVC Applications don’t fall to the same older problems that procedural Applications would.

Thanks for the approach on webroot vs. non-webroot – I just always had been steered to keep stuff out of webroot when possible in the past. Also, regarding Save Class File, it’s very helpful to know that it’s not a ColdBox-specific problem.

Is there any documentation from Adobe or good blog posts that details the expected conflicts enabling Save Class Files (the default) and sharing code between applications? I don’t manage the server (shared among several departments) and it will be difficult to make a case to change settings without some documentation as the only one being affected. Unfortunately, it seems most documentation I run across simply says, turn off for developement and on for production.

If we can’t change the Save Class Files setting, then multiple copies of Coldbox should work, then, yes?

Thanks again,
Wes

I think this is the best article you will find.

I had forgotten about the performance hit, but that might be marginal in the whole aspect though. However it is a known best practice to just turn these off.

http://cfmlblog.adamcameron.me/2013/08/saving-class-files-in-coldfusion-and.html

And it should be noted, that those settings are pre CFMX days. All versions of ColdFusion since then have no need for this feature. Follow down to class files for what this article says.

http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance.html

but basically, the premise is switch them off. If you have issues with this, then my attitude is you need to work for people who actually know what they are doing. Not saying they don’t, but they should know what this setting is used for if they Administrate ColdFusion servers.

Hmmm… I thought it was the “Cache Web Server Path” and also the “Component Cache” that would cause these issues with multiple sites on the webserver? I confess that I have not run ACF in several years though so perhaps I am mistaken.

ADK is correct. The settings you need to disable are “Cache Web Server Path” and “Component Cache”. There is absolutely nothing wrong with saving class files or using trusted cache across multiple CF applications that all point to the same ColdBox folder. I have done this many times without issue. I would not recommend tuning of the saving of class files or trusted cache in production as they provide a good performance boost-- especially when restarting the CF services.

Thanks!

~Brad

Actually Brad, the performance boost it used to give is almost mute. That setting was introduced when ColdFusion had very bad performance in creating objects.

With the massive increase in hardware performances over the last 14 years, that setting is nearly mute. I actually did find an article on why this setting was introduced and now I can’t find it.

But you are right, it is the two Andrew(ADK) mentioned. as I was extremely tired when I replied I wasn’t thinking straight and have always turned those features of in development. In production I would not have the faintest as to what they are set too, as this is controlled by the System Administrators, but I am sure it will be on.

It will not hurt to leave the save class option on, but the performance gain is so marginal on today’s version of ColdFusion and hardware than what it was 5 - 20 years ago. Can’t believe ColdFusion is approaching the Big 20 very soon, I will need to look it up to confirm this but I am sure we enter the 19th year next month.

Actually, the biggest bottlenecks I’ve seen with the trusted cache settings on my servers is not the compilation but the disk IO checking the file last modified date from the filesystem on every request. Most web servers don’t have crazy fast hard drives because they don’t need large IO, but checking every single file repeatedly on a large site can add up.

Also, it’s “moot”, not “mute” :slight_smile:

Thanks!

~Brad

Yes it can add up, but the distinction in what it used to be 15 odd years ago too today is moot (knew it didn’t look right when I typed it) But I do agree it should be left on, most developers here would not be requiring such performance for development and in most cases will be having very small users where they would not see such performance gains.

By the time most developers get to that stage, they are actually looking after servers that have insane concurrent usage where you need such tweaks.

So my advice, take it on board as what Brad says, it wont hurt. But it is also something you don’t need in development, unless of course you’re doing a staging server where you are going to run concurrent tests to test performance.

Can I add that around 5 years ago, maybe 6 I wrote a caching of components using serialization of components. This part of the application was to find a way that we could make DB changes and version control code changes to a DB. The way I would have liked to have gone, was not possible in those days so this was the quickest and dirtiest way to go about this.

The idea was simple, we could role back the DB schema, in the same way we can do Source Control.

Anyway, the idea was to serialize the component and load that instead of the real component. I was asked why we don’t do this in the DB itself, at the time I wanted to exclude the DB as it wasn’t something I thought should be added at that tier. Being a small niche market the Application was aimed at, I just wanted to have it separate. Till someone said that the DB would be faster in retrieving it from the HardDrive.

In terms of settings, all those settings where actually switched of on my machine and the test machine it was run on. The difference in getting it from the DB and getting it from a file, was like 0.01ms (avg) of a difference. These where normal DeskTop machines, built to be stage and Development servers, so they where nothing special. Under a march higher load those figures might be different, as if the servers had been actual servers designed to be a server.

On one site, I had been logging to a log file. The site is not heavy, but logging to the file in those circumstance didn’t add much more execution overall to the site and yes there was about 20-50 lines added to the log each user. I have eventually moved it to the DB and the execution times aren’t that much of a difference, but these servers are built for high IO so I doubt I will see much of a difference.

I just wanted to throw that out there, because sometimes the IO is not that different in speed.

I guess this is the same as how I see massive ORM slowdowns when using Criteria Building on most servers I run ContentBox on, yet you seem to not have that issue.

Guys, I really appreciate the wealth of information here. Being a relative newcomer to ColdBox, or any system for that matter, it is often difficult to know how far off from the correct solution you are when you experience weird behavior. Is it the server config, or my code…or my brain?? Usually resolving the latter wins the day.

My takeaway here is that if I disable Component cache and Cache web server paths then I should not experience problems with sharing common libraries, specifically the ColdBox core, among multiple applications on the same server instance. Enabling Save class files may yield a performance gain in production (depending on hardware), though I admit I’m still a little foggy if it can actually cause problems itself and in what scenarios that would be.

Thanks for taking time to write, you’ve all been a tremendous help!

Wes

I am not aware of any problems “trusted cache” can cause other than if you modify a cfm or cfc file and refresh the page, it won’t pick up your changes. Of course, that’s sort of the point of that setting. The good news is you can programmatically clear trusted cache so you can still automate deployments with the click of a button.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com