Element xxx is undefined in CFML structure referenced as part of an expression.

[Chris G]

Lastnight, I ran my first FrogQuest event ever, a huge milestone for me, however I ran into several errors I'd never seen before nor do I understand and was  hoping one of the CFWheels Gods out there could shed some light on since they seem to be issues with the framework itself.

Here they are in summary, but I'm attaching screenshots of the errors as well if more information is needed.

1. Element Jobs is undefined in CFML structure referenced as part of an expression.
   The error occurred in wwwroot\wheels\controller\initialization.cfm: line 49
   
   
2. Element maillog is undefined in CFML structure referenced as part of an expression.
   The error occurred in wwwroot\wheels\controller\initialization.cfm: line 205
   
   
3. Element tasklist is undefined in CFML structure referenced as part of an expression.
   The error occurred in wwwroot\wheels\controller\initialization.cfm: line 205
   
   
4. Element sale is undefined in CFML structure referenced as part of an expression.
   The error occurred in wwwroot\wheels\controller\initialization.cfm: line 205

FYI: Jobs is a controller, while maillog, tasklist, and sale are all models in my application. 

[Yannick Morin]

Are you sure you are running in wheels production mode?

--
You received this message because you are subscribed to the Google Groups "ColdFusion on Wheels" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cfwheels/-/UYLJWq0sA-sJ.
To post to this group, send email to cfwh...@googlegroups.com.
To unsubscribe from this group, send email to cfwheels+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cfwheels?hl=en.

[Chris G]

good question, Yannick! I should have made that clear. I was getting errors, but wasn't receiving the error notification emails, so I put the production site into design mode so I could see what was going on. This is how I got these screenshots.

[Yannick Morin]

Can I see one your model init

To view this discussion on the web visit https://groups.google.com/d/msg/cfwheels/-/gytJZYDzuuoJ.

[Chris G]

MailLog has no init

Here's tasklist... 

<cffunction name="init">

<!--- Associations --->

<cfset belongsTo(name="task")>

<cfset belongsTo(name="event")>

<cfset hasMany(name="tasksubmission")>

</cffunction>

[Yannick Morin]

Try in testing mode it will do the caching like in production but show the errors on the screen

To view this discussion on the web visit https://groups.google.com/d/msg/cfwheels/-/ImCsZwUbQYoJ.

[Chris G]

I'm concerned about these errors. I don't understand what could be causing them and would appreciate some insight from whomever has it to offer. These errors aren't thrown consistently. As I mentioned below, I'd never seen them prior to being in production, but I just received the maillog error in design mode. The template calling the model is making the call as such...

        log = model("maillog").new();

pretty standard. As I told Yannick, there is no init methods in the maillog model. So, what could it be? I'm desperate any direction here!

[tpet...@gmail.com]

when things list this happen, the first thing to do is to get wheels (or any framework for that matter) out the equation altogether. Make sure that there is no url rewriting happening. Now, comment out the cfinclude line in the index.cfm in the webroot. now just do a normal cfquery and cfoutput to make sure that you can hit your database and retrieve records from it. if that works then onto step two.

uncomment the cfinclude in index.cfm and see if you can load the welcome screen. does it come up?

[Chris G]

Thanks for the advice! I'm not quite sure I understand completely, but I'll take a closer look this afternoon and see if I can figure out how to do that with what you've provided.

In the mean time, Yannick requested the call in the controller (in another thread), so I thought I'd provide that. As I said, it's pretty standard. I get this error when calls to a controller or model are made, most of which are more complicated than this example. I've chosen this one because it is the simplest. As I've said before, the maillog model doesn't have any associations in the init and is a stand alone table.

log = model("maillog").new();

[set various properties]

log.save();
		

[Andy Bellenie]

Hey Tony, you give really good advice on approaching Wheels debugging. If you have a sec, why not write it up as a blog post? I have a feeling it will save some time responding to support emails :P

--

You received this message because you are subscribed to the Google Groups "ColdFusion on Wheels" group.

To view this discussion on the web visit https://groups.google.com/d/msg/cfwheels/-/apidOa171iEJ.

[Risto]

This is my experience with this error.

I pop these errors once in a while and it is always a problem related to a structure key/value I'm comparing or evaluating.
You should probably dump struct keys or struct values and see if something is strange. You say it doesn't happen consistently, so maybe you are evaluating some struct value and
there is a  scenario where the struct value is blank or doesn't exist. I know something as simple as an extra space on a struct key when you are doing
a comparison expression causes this error as well. Can't see your code, but I have had this error multiple times. It's never been related to cfwheels in my cases.

[Chris G]

Risto,

thank you for chiming in. I'll do a full scrub and see what I can find. 

Chris

[Chris G]

Ok, I'm frustrated. I've spent the last week basically rewriting this entire process because I wasn't able to find any problem in the key/value structure and thought that by rewriting, it might root out the problem through in-depth analysis. But, I'm still getting very similar errors. Not every time through, mind you, only sometimes. But often enough that it can't be ignored. The error is essentially the same, though now it's with a different model. I'm attaching a screenshot of the error and below I'm copy/pasting the code actual code referenced in the chain leading up to the error, starting with my templates and following them into the wheels core files. This is ACTUAL, unaltered code. I can't see why this wouldn't work as the model call is pretty basic. Where am I going wrong here? Is this a wheels bug?

Called from D:\Dropbox\www\dev.frogquest.com\controllers\Submissions.cfc: line 12

12> result = subWorkflow();

Called from D:\Dropbox\www\dev.frogquest.com\controllers\Submissions.cfc: line 130

130> savedSubmissionSuccess = saveSubmissionSuccess(thisEmail);

Called from D:\Dropbox\www\dev.frogquest.com\controllers\Submissions.cfc: line 558

558> sub = model("submission").new();

Called from D:\Dropbox\www\dev.frogquest.com\wheels\model\crud.cfm: line 60

60> loc.returnValue = $createInstance(properties=arguments.properties, persisted=false, callbacks=arguments.callbacks);

Called from D:\Dropbox\www\dev.frogquest.com\wheels\model\crud.cfm: line 935

935> loc.returnValue = $createObjectFromRoot(path=variables.wheels.class.path, fileName=loc.fileName, method="$initModelObject", name=variables.wheels.class.modelName, properties=arguments.properties, persisted=arguments.persisted, row=arguments.row, base=arguments.base, useFilterLists=(!arguments.persisted));

Called from D:\Dropbox\www\dev.frogquest.com\wheels\global\internal.cfm: line 433

433> <cfinclude template="../../root.cfm">

Called from D:\Dropbox\www\dev.frogquest.com\root.cfm: line 1

1> <cfinvoke attributeCollection="#arguments#">

The error occurred in D:\Dropbox\www\dev.frogquest.com\wheels\model\initialization.cfm: line 205

205> variables.wheels.class = $namedReadLock(name="classLock", object=application.wheels.models[arguments.name], method="$classData");

[Chris G]

I realize that this is NOT the proper way to address this issue, but I'm at the end of my wits with this one. If anyone has a better idea, I'd love to hear it, but for now this seems to be working. Since it's not occurring every time, I'm giving it two chances at success by using a try/catch trap as such...

try{

sub = model("submission").new();

} catch (any e) {

sub = model("submission").new();

writeLog(e.message);

}

I haven't actually noticed anything written to the application.log file, which seems bizarre. But I haven't seen a single failure in somewhere between 100-200 attempts. I'm not sure how often it was failing before, but probably at least 10% of the time or more.

[Per Djurner]

So the application.wheels.models struct does not contain the object, right?

Three reasons this can happen:
1) The ColdFusion service is being restarted at the same time as your request.
2) A reload request is being executed at the same time as your request.
3) get("cacheModelInitialization") is set to false (which it is in
design and development mode for example) and someone else is running a
request involving the same model at the same time as your request.

On Tue, Dec 4, 2012 at 12:54 PM, Chris G <chris....@gmail.com> wrote:
> application.wheels.models

[Chris G]

Interesting. So I've seen this happening on my development machine (design mode), in testing (testing mode), and in production (yep, production mode). So, I doubt very much it could be 1 or 3.

However, 2... I don't think so, but tell me what you think.

This page does the following...

1. downloads the top 20 email headers and caches the query in session

2. downloads one email in its entirety and processes it (validates it's parts, organizes the attachments, logs, adds to the DB, etc)

3. At the end, it redirects to itself using redirecTo() and repeats the process (except it uses the cached headers until it has downloaded all 20)

4. at the end, I rest and set a meta redirect to kick off the process again

I know it seems funky to do so many redirects, but its the only way I can avoid the timeout limits. Sometimes downloading 20 email headers is incredibly slow, sometimes it's quick. I can redirectTo up to 21 times before the browser stops the process, which is why I rest for a few seconds to let the meta redirect start it off again. 

But I'm not processing any redirects mid-control, just at the end, once the process has already concluded. So unless some of the controller processes are happening async to the redirects, I don't see how this could be the problem. Thoughts?

FYI: I also tried CFThread to async download the emails to avoid the timeouts. This worked great until I went to production. Apparently, ACF doesn't play well with threaded apps in a co-hosted environment. 

[Per Djurner]

What you do in the code shouldn't matter at all actually.
The fact that it runs for a long time makes the problem more likely to
appear though.
Maybe log or send yourself an email when reloads occur to see if they
happen at the same time bugs are?
You can just look for url.reload in onrequeststart or something like that.

> --
> You received this message because you are subscribed to the Google Groups
> "ColdFusion on Wheels" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/cfwheels/-/0cnCY9oxk9sJ.

[Chris G]

Per,

This is really interesting. Do reloads occur without my explicitly requesting it? How, when, why?

Chris

[Per Djurner]

Well, that's what you'll hopefully find out if you log it :)
Make sure to include the user agent, IP address etc so you get all the details.

> https://groups.google.com/d/msg/cfwheels/-/IdIbRw2gv2YJ.

[Chris G]

I did as you suggested. In 24 hours, I've noticed zero unexpected reloads, but I'll leave it in place for now and see what happens.

Also, I'm about ready to call this issue resolved. I did the most extensive test yet yesterday, downloading and processing 500 emails without a single error thrown, whereas before I couldn't get through 30 without throwing an error. I'd say that's good progress!

Interestingly, the try/catch doesn't ever seem to be getting to the "catch" part because I'm not seeing any messages in the error logs, but there's always the possibility I'm not looking in the right place either.