Good morning CF friends,
Yesterday I finally debugged an ongoing issue that we had determined was an undocumented issue with the past hotfix for CF2016 - which we now know was not entirely true.
The issue was that every so often one of our 8 JVM instances in our CF Cluster would show an error for an application that was looking at the same code base for the same application. The cfcatch error was for missing include template files that were working great after a reboot of the same instance and fine on the other instances.
What was discovered, is that during the last update (5) the ownership had been changed to root:root on the /opt/coldfusion2016/sec-apps-2/wwwroot/WEB-INF/cfclasses contents that were existing at the time on that single instance (default behavior when applying the update). However, there were no indicators of what the problem actually was since during a reboot everything worked great again with no errors showing up in any log files when it presented itself.
The issue would show up only after pushing new changes to our applications and clearing the template cache or component cache in the cfadmin.
When we were able to reproduce the production issue on our test environment what we discovered is that the really nifty feature of "Trusted Cache" being enabled along with bad ownership permissions propagated it.
Here is how the logic pathways appear to flow :
1. Server Instance started or rebooted running with non root user
2. Application accessed for the first time, the instance is unable to see class files (wwwroot/WEB-INF/cfclasses) because of root:root permissions on the existing compiled files and the filesystem is read entirely for the includes because no trusted cache has been established.
3. The class files are then compiled and stored in CFClasses (wwwroot/WEB-INF/cfclasses) and an entry made in Trusted Cache. However, the class files are unable to overwrite the existing root:root owned files with the same name "due to the Trusted Cache token appended on the end that has not changed" - but no errors in any logs.
4. New application changes are pushed to the filesystem and the template cache / component cache is cleared. The Trusted cache has a record of compiling those files (even though they were not written successfully) and tries to access them from the cfclasses directory where they do not exist.
5. The error thrown is explicit in that the cfinclude template file is missing from the filesystem - but what it really means, is that it couldn't find it in the cache and refuses to look for it on the filesystem since it is part of the trusted cache scope...
NOTE : This has occurred for both cfinclude files and cfobjects - with the cfobjects, it simply tells us that the object cannot be found
Here is an example of the cfinclude error once the instance is running and the Template Cache / Component cache has been cleared :
Our CF Instance Specs (Running on RHEL 7) :
I saw someone post this same issue about cf11 : Strange behaviour cfinclude with CF11 and Yosemite
If this is working as designed - it might be helpful to error out when unable to write a compiled class file that already exists.
That is all : ) - I hope this proves helpful to those out there with the same issue.
2
Replies
AdChoices