Major Production issues

I just launched a new site in production and I am having major problems. I already had my personal site running in production but now i added a new app called toysforshots. They both run off of the same mapping /coldbox

When i start the server up and run either app that app works. The second app does not, it appears from debugging info that it loads up the others config file. How on earth can this be happening if they both have unique app names and unique names in coldbox config.

I have one app down, if anyone can help me at all I would really appreciate it.

Do you have access to cfadmin? There is a cache setting that needs to be turned off which maybe the culprit.

Nolan Dubeau

Load .,8,1

Uncheck cache component paths might do the trick.

Nolan Dubeau

Load .,8,1

wow, that was the issue :frowning: I also noticed it was happening on my local machine. any idea why this happens? component cache is a good thing to have on no? I am hitting the sack but I will investigate further tomorrow…thanks for the help!

Good stuff. Yes I think component cache components is great to have on for sites that don’t use shared frameworks. But for CB you need to have this on to avoid collisions. I found this out the hard way as well. If it’s not already documented it might be good to document this with high visibility on the CB wiki.

Nolan Dubeau

Load .,8,1

Believe it or not MOST hosting providers turn this of when on shared hosting, for that exact reason.

And is also the first thing that I switch off on any new ColdFusion installation, for that exact reason. I also learnt this the hard way, and it doesn’t just apply to ColdBox but it applies to all ColdFusion files and Components as well.

At least that was my initial findings, but as I do switch it off I haven’t really gone looking into it in depth either.

Thank you guys so much for the help and the information!!

This is one of the reasons that I like to use a per-application
mapping to coldbox and the "bootstrapper" version of Application.cfc
http://wiki.coldbox.org/wiki/Bootstrapper.cfm

John, please don’t take this the wrong way, but whether you extend Application.cfc or go with the non inheritance of Application.cfc they are all bootstrapping.

Also what Dan has discovered is when two or more Applications share the same ColdBox instance, whether this is ColdFusion mappings or not has no bearing on the problem.

The problem is with the cache, it caches the file and path, and everything else it loads up, configuration and all. So when the next Application comes along, ColdFusion says wait a minute and loads up the cached copy, with all the configuration of the previous Application.

And to fully understand that you need to fully understand how ColdFusion caches components.

I hope that clears the situation and the problem more, and like I stated earlier this is not a ColdBox issue, but a known limitation in the way ColdFusion works.

Now if you read the notes in the Administrator it makes it very clear, that it caches the path and will not be resolved again. Which clearly says that the first one to run will be the one cached, now in the nature of all singletons and the way ColdBox and other frameworks are designed, this becomes a huge issue when using the same framework location across multiple sites, as Dan has just found out.

So you can see no matter how ColdBox is boostrapped, nor how it is mapped, per application or not. It will always be a problem because it will be cached by its known path, and that is why this is an issue.

Again I hope that clears this situation up some more.

Just jumping in here - is there any benefit to NOT adding a coldbox mapping inside CF and, for instance, symlinking to coldbox per application instead? That way the paths can be cached.

I’m just wondering whether component path caching has any dramatic performance increase, and if so maybe this would be something worth looking at (for us *nix users of course).

Tom.

Not sure to be honest with you.

But I will answer it this way!!

If that ever becomes an issue, then you should be having a dedicated server just for your application anyway.

I don’t believe symlinking would do anything, unless you mapped it to a different name.

For instance, you have two apps on your server, in different web roots, both asking for “/config/coldbox”. Even though they are asking for the same component path, they are referring to two different physical files. The only way I can think of is if you forced all component paths to be different between both apps. (With the possible exception of the core ColdBox framework, as long as they are sharing the same one)
To be clear, CF is not caching actual component instances with that setting, just a resolution from the path to the physical .cfc file.

So for it to work, you wouldn’t use ANY paths based on the web root, and instead created mappings called “site1” and “site2” which pointed to the respective web roots. Then you would have to prefix EVERYTHING in each site to use the “site1” or “site2” mapping to resolve.

Then, the two configs would have these paths:
/site1/config/coldbox
/site2/config/coldbox

ColdFusion would cache those paths to the respective physical files, but since the paths are different, you wouldn’t get any overlap.

All that being said, I don’t know how much performance that settings gives you so I don’t know if it’s worth all the trouble.

Thanks!

~Brad

Symlink, CF mapping, physical directory. Doesn’t matter. As Andrew has explained, if component caching is turned on, you cannot use a CFC with the “same” path in multiple places. It’s just how CF works. It’s one of the ways Adobe chose to fake the performance improvements. (I say “fake” because it has extremely little real-world value, since your average application requires it be turned off as a result of the issues discussed here.)

To help explain it a bit more, forget ColdBox for a moment. Imagine you have Aplication A and Application B. Neither one uses ColdBox at all, but both have a UserService that resides at ‘com.user.UserService’. Even though each app has its own UserService, and even though the code for each is entirely different, if the caching is turned on, whichever app loads ‘com.user.UserService’ first is the one that will get its correct service object. The other app will get the wrong one.

Why? Because that setting in CF Admnin is turned on, so when the first request for ‘com.use.UserService’ (since the last CF restart) comes in, CF goes and locates that path (‘com.user.UserService’). The next request for that path comes in and CF says “ah, yes, I already found that one and it’s in my cache… here ya go”, and gives you the wrong object (if hitting from another application).

In a nutshell, if the server runs more than one application, turn component caching off. It will give you zero bebefit because you will fight this issue over and over and over and over again. That setting is completely worthless unless you have a massive application with massive traffice spread across multiple CF instances, and your application is the only one running on any of those instances. Since extraordinarily few applications fit into that category, turn it off. It is a totally bogus “performance enhancement” for the average user.

Really great explanation guys!

Especially as it was “sent from his iphone”!!!

Good point Andrew, yes, you’re right.

  • John

– sent by a little green robot