I am seeing random "Could not find the included template" exceptions on my ColdFusion website. They are always for one file, but that file does exist and is included hundreds of times throughout the website and I don't see errors 99% of the time. The error only occurs randomly (6 times in the past 4 weeks). I would like to know why this is happening and how I can prevent it.
You say the file is a footer and that it "is included hundreds of times throughout the website". Do you mean at hundreds of page locations? If so, then this suggests a possible design flaw.
You should strive to include the footer in one location only, the Application file. (Or failing that, in as few locations as possible). It is likely that the error is being caused by cfinclude code in a page that is accessed 1% of the time.
Related
Good day -
My work group upgraded from CF10 to CF2016. We have finished 2 of the 3 servers that run the application behind a load balancer.
Since the two servers have been upgraded, we get an occasional (<<1%) error on <cfinclude> statements:
The process cannot access the file because it is being used by another process
The included files are different each time, but they have the same characteristic: the names are dynamically generated in the cfinclude tag. For example:
<cfinclude template="#fileManager.getFile('appl1')#">
where #fileManager.getFile('appl1')# simply returns a string path to a CFM file. The file definitely exists, and it is not e.g. being modified by a programmer or any other (known) process. The files themselves are generally just simple index.cfm files in directories that haven't been touched in a year.
This only happens on dynamically named templates in <cfinclude>, never static template names.
Here are the cache settings on the server. Please note that the settings are the same on the server that doesn't experience this problem (the CF10 server)
Any ideas what can cause this random, fleeting error? I can not establish any pattern other than CF2016.
We have a collection of VB.NET / IIS web services on some of our servers, and they have web.config files in the websites' root directories that they're already reading configurations from. There is a new configuration that needed to be added that will immediately be quite a bit longer than the others, and it'll only stand to grow. It's essentially a comma-separated value, and I'm wanting to keep it specifically in a configuration file of some sort.
At first I started doing this with a text file, but there was a problem with that. The text file's contents could change while web service threads and processes are running, so they would need to essentially re-read the file every time they needed to access its values. I thought about using some sort of caching, but unless the web services are completely restarted each time the file is updated, caching would block updates to the file from being used immediately. But reading from a text file each time is slow...
Then came the idea of putting that value in web.config, along with the other configurations the services are already using. When web.config is altered, the changes are able to be cached in the code, on top of coming into play immediately. However web.config is, well, web.config, and it's not a totally trivialized text file that is simply read out of in the code. IIS treats web.config in a special manner.
I'm tempted to think any negative consequences of putting a comma-separated value in web.config would be outweighed, in comparison to storing them in a text file (or a database, which probably can't be used for this anyway), but I guess I better ask.
What are the implications of storing a possibly lengthy, comma-separated value in web.config, instead of in its own little text file? Is either file a particularly good or bad idea? To me, it seems like web.config would be easy to get along with without having to re-read the file over and over, but there's certainly more to it than the common user is aware. Thanks!
I recommend using the Application Cache for this:
http://msdn.microsoft.com/en-us/library/vstudio/6hbbsfk6(v=vs.100).aspx
I am on a four month coop with a web development firm, and am currently trying to implement some new functionality to their project management tool. I have the source and am trying to get it set up locally for testing purposes.
I am using windows 7 and wamp.
I have spent the entire day today failing with this, have found dozens of similar (potentially identical) questions on stack overflow which have not assisted me, and read the documentation on the php.ini that seemed related.
The code - not mine - uses a constant ROOT value which I have set to work with my structure.
define('ROOT', '/ac_test/public_html/||||'); (|||| is just the software they use).
When I load up the index.php file it attempts to include a file:
require_once ROOT . '/defaults.php';
At this point it fails and gives me this error:
Warning: require_once(/ac_test/public_html/**/defaults.php) [function.require-once]: failed to open stream: No such file or directory in C:\wamp\www\ac_test\public_html\config\defaults.php on line 14
Fatal error: require_once() [function.require]: Failed opening required '/ac_test/public_html/||||/defaults.php' (include_path='*PATH ATTEMPTS BELOW') in C:\wamp\www\ac_test\public_html\config\defaults.php on line 14
I have altered the include_path in my php.ini file to be just about everything. I've attempted relative paths (.;..;../../../.. etc), I have attempted direct paths (c:/wamp/www for example) and probably 20+ other nonsensical possibilities. I have used get_include_path() to output the path which ends up being identical to where the file is, and I have used the full, direct path without using ROOT, and it works, but I can't use that. There are hundreds of coded references in the code that require me to use the ROOT constant and for the include_path to function.
I realize this question has been asked before, many many times. I've likely read every post on stack overflow today regarding it. They're all similar. So is mine, but I'm out of ideas. I should also mention that I began web development and php only 2 months ago with this coop. I have some very big holes in my knowledge, and so I may have overlooked something very simple.
I maintain an application that collects data from a datalogger and appends that data to the end of a binary file. The nature of this system is that the file can grow large (> 4 gigabytes) small steps at a time. On of the users of my application has seen cases on his NTFS partition where the attempts to append data fail. The error is being reported as a result of a call to fflush(). When this happens, the return value for GetLastError() is 665 (ERROR_FILE_SYSTEM_LIMITATION). MSDN gives the following description for this error
The requested operation could not be completed due to a file system limitation
A search for this error code on google gives results related to SQL server with VERY large files (tens of gigabytes) but, at present, our file is much smaller. This user has not been able to get the file to grow beyond 10 gigabytes. We can temporarily correct the situation when we do some operation (like copying the file) that forces some sort of rewrite in the file system. Unfortunately, I am not sure what is going on to put us in this condition in the first place. What specific conditions in an NTFS file system can lead to this particular error being reported on a call to fflush()?
This sounds like you've reached a limit in the fragmentation of the file. In other words, each flush is creating a new extent (fragment) of the file and the filesystem is having a hard time finding a place to keep track of the list of fragments. That would explain why copying the file helps -- it creates a new file with fewer fragments.
Another thing that would probably work is defragmenting the file (using Sysinternals's contig utility you may be able to do so while it's in use). You can also use contig to tell you how many fragments the file has. I'm guessing it's on the order of one million.
If you have to flush the file frequently and can't defrag it, something you can do is simply create the file fairly large in the first place (to allocate the space all at once) and then write to successive bytes of the file rather than append.
If you're brave (and your process has admin access), you can defragment the file yourself with a few API calls: http://msdn.microsoft.com/en-us/library/aa363911(v=VS.85).aspx
coldfusion.compiler.FactoredNodeAggregation cannot be cast to coldfusion.compiler.ASTfunctionDefinition
I get the above error when attempting to replace a really, really old legacy custom tag with a new custom tag that has some substantial workflow improvements. I only have one idea on how to debug this: comment out different parts of the code (binary search style) until it will compile, narrowing my search until I find the problem code.
Has anyone else ever seen this error before? Any idea what it could possibly be? Contextually, it sounds like I'm trying to use ... something... as a function that isn't defined as a function. That doesn't ring a bell so I'm going to try the binary search idea.
Update: It's running on CF 8.0.1, and doesn't use any <cfscript> blocks at all. Using the binary search of commenting out, I've narrowed it down to a CFThread that starts a background thread that never re-joins the page (by design).
If I comment out the entire contents of the thread, the error goes away (so the cfthread tag itself doesn't appear to have problems on its own...). If I copy the contents of the thread to its own template, that template will compile fine (so the thread contents doesn't appear to have problems on its own...)... so... in theory it should work? I don't know. This is me with my arms up in the air. (WTF?)
I think I've already disproven this idea by un-commenting a small section without the error coming back, but a CFThread should have access to local custom tags that the template creating the thread would have, right? so if there's foo.cfm, it could be accessed from the page as <cf_foo>, and the thread could do the same?
In the last week I've been in contact with the ColdFusion Engineering team at Adobe about this issue and they confirmed for me that this is a bug in ColdFusion.
Specifically, if the number of lines of code inside the thread tag body was too large, it would cause a compile error. The work-around, which I discovered a day or two before I got my answer, is to use a <cfinclude /> to import your thread contents from another file; or to put the code into a method somewhere and call that method from inside the thread body. (Presumably, a custom tag or other clever methods of encapsulation would also work.)
That explains the part of the whole thing that was driving me absolutely insane: that commenting out various parts of the thread body would sometimes make it compile... and now I know it was because enough of the thread body was commented out.
They report that they have fixed the bug, so I assume it will be fixed in the next cumulative hot-fix (if there is one), and in ColdFusion 9.
Since I can't comment yet, Adam, is it really a bug with CF or with the JVM? There's a similar limit on how many lines of code can be compiled within a CFFUNCTION, but the limit is really in the JVM, not the CF tag.
Oooh, that's one I've not seen before.
Depending on what the custom tag does, rather than commenting out different parts, you could try using cfabort - same technique, but only one line to change rather than uncommenting and re-commenting (which can be fiddly and time-consuming).
Also, are you able to test the custom tag in isolation, with completely simplified arguments/etc?
If you're able to post the code, there might be something odd that jumps out at a fresh pair of eyes?
that error usually comes up when you have a function that is set to remote. kinda funny that your getting it with a custom tag though. are you sure that the custom tag doesn't have any functions in it? can you post the code?
Strange that it is a compilation error. If the code base is not too huge I would make sure all variables in the thread and called udfs are explicitly scoped.
Next I would move as much externally referenced data into the thread arguments scope to isolate the interactions with the page.
Finally if that does not clear it up I would try mangling the names of every variable, function and udf the thread accesses a bit with some test prefix just to make sure that you have not hit a bug where one of your vars or funcs is causing a namespace collision in the jvm in the context of the original page.
Tricky problem.
Have you deleted the compiled class files and saved the original source to a new file just in case something weird occurred during a save?
Have you tried reinstalling CF8.01? Maybe some files got corrupted?