Can you post the code for the set_first_name.cfm? "firstName variable is undefined".
I have seen this type of error before when the variable is set to null. Something like a web service call that fails or really does not return anything. In this instance "setName" might be a function that returns 'void', so firstName would be null. <cfinvoke method="setName" webservice="...?wsdl" returnvariable="firstname"> ..... </cfinvoke> You could test this by checking isNull(firstname). I would think if the byte code was incorrect you would not be getting CF error details about what is going on and probably get some sort of java servlet 503 error instead. Byron On Wed, Sep 17, 2014 at 5:07 PM, Dave Watts <[email protected]> wrote: > > > > How do you know this? What do you mean exactly by "incorrectly > compiled"? What version of CF are you running? > > > What are the exact error messages you're seeing? > > > > The reason I know it's not being compiled correctly is because when this > issue occurs, the errors that happen are > > indicative of the .cfm file being in place, but the byte code being > empty. > > > > What I mean is, let's say page.cfm does a cfinclude on a high volume > file called set_first_name.cfm which simply > > sets a variable called "firstName". > > > > If that file is "corrupted" in the way I am describing, a "firstName > variable is undefined" error would occur when > > firstName was referenced back in page.cfm (after the cfinclude). Because > even though the included > > set_first_name.cfm file does indeed exist, the byte code that was > generated is behaving as if it is "blank" (for lack > > of a better term). > > > > I haven't personally examined the byte code, but 1) I don't have access > to the live server, and 2) I wouldn't really > > know how to read it. > > Well, my take on this is that you wouldn't see this problem if the > file is corrupted. Instead, the entire page would simply fail to > render unless you had the CFINCLUDE in a CFTRY/CFCATCH. The generated > byte code has to be a fully-formed Java class that conforms to the > Java Servlet API, and it seems to me to be unlikely that the class > would be created correctly but just without your custom code. Again, I > don't know enough about the internals of CF to guarantee this, but I > do know a little bit about compilers and Java, and it seems unlikely. > > It would be useful if you could simply compare the bytecode size > between "good" and "bad" versions of the same compiled class, if you > could access those from the live server. They may be written to disk, > in the cfclasses directory, if you have "Save cache files to disk" > enabled in the CF Administrator. > > > > I've never seen this problem, even in many high-volume environments - > some of which had their own problems. > > > And it doesn't really make sense, given my (admittedly limited) > knowledge of CF internals. So, I kind of think this > > > is unlikely. Something else is probably happening. > > > > You may be right, but this is what we're experiencing. I also admit a > limited knowledge of CF internals. > > I guess what I'm getting at here is: you definitely have a problem. > But I don't think your description of the cause of the problem is > accurate at all, and you could easily go down a rabbit-hole here by > focusing on what you imagine is the cause of the problem, rather than > the problem itself. The basic description of the problem is that > you're not getting the output under load that you get without load, > right? > > What happens if you block incoming traffic to the server, stop and > restart the CF service, and rerun the same pages, with "Save cache > files to disk" enabled? My guess is that you'll get the correct > output. > > > > That article isn't really related, although it could solve the problem > you describe. You can precompile CF code, > > > then deploy that instead of the source code. You could try doing this > to solve your problem, but again I don't > > > think that's really the problem you're having. > > > > I agree that the article is only somewhat related, but it is related in > the fact that, yes, there seems to be some sort of > > problem with the compilation process. We have thought about deploying > the compiled code, but wanted to see if anyone > > else had experienced this problem first. > > You could certainly try to just deploy compiled classes and see what > happens. It's generally a good thing to do in production anyway. > > Another approach you could try is to force the server to precompile > everything by running a test script that generates an HTTP request for > each CF file before you open access to users. > > Dave Watts, CTO, Fig Leaf Software > 1-202-527-9569 > http://www.figleaf.com/ > http://training.figleaf.com/ > > Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on > GSA Schedule, and provides the highest caliber vendor-authorized > instruction at our training centers, online, or onsite. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:359324 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
