Known Participant

Question

CF looking at arrays as a struct and throwing errors

Forum|Forum|19 years ago
September 14, 2006
17 replies
2416 views

I am getting the following error:

Object of type class coldfusion.runtime.Struct cannot be used as an array

This occured a coupleof days ago for the foirst itme. I restarted the CF service and that fixed it. It happened again today and niether restarting hte service nor rebooting hte server has solved the problem. The arrays are definitely getting declared as arrays and we are not using structs or and struct related functions onthe site. Any insight on this would be greatly appreciated. Here is the full error with stack trace. Thanks in advance

Eric

Object of type class coldfusion.runtime.Struct cannot be used as an array

The error occurred in D:\iremroot\sechome.cfm: line 25

23 : <cflock scope="Session" timeout="10" type="Exclusive">
24 :
25 : <cfif isDefined("Session.navArray") AND ArrayLen(Session.navArray) GTE 17>
26 : <cfset SECTION_ID="#Session.navArray[3]#">
27 : <cfset sContentInsert_1="#Session.navArray[4]#">

--------------------------------------------------------------------------------

Please try the following:
Check the ColdFusion documentation to verify that you are using the correct syntax.
Search the Knowledge Base to find a solution to your problem.

Browser Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Remote Address 30.30.3.61
Referrer https://secure.irem.purplemonkey.net//home.cfm
Date/Time 14-Sep-06 04:46 PM

Stack Trace (click to expand)
at cfsechome2ecfm642595352.runPage(D:\iremroot\sechome.cfm:25)

coldfusion.runtime.NonArrayException: Object of type class coldfusion.runtime.Struct cannot be used as an array
at coldfusion.runtime.Cast._List(Cast.java:956)
at coldfusion.runtime.CFPage.ArrayLen(CFPage.java:347)
at cfsechome2ecfm642595352.runPage(D:\iremroot\sechome.cfm:25)
at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147)
at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357)
at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:62)
at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:107)
at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:43)
at coldfusion.filter.PathFilter.invoke(PathFilter.java:80)
at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:47)
at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:35)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:43)
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.CfmServlet.service(CfmServlet.java:105)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:304)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.FilterChain.service(FilterChain.java:101)
at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91)
at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:252)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:527)
at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:192)
at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:348)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:451)
at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:294)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

This topic has been closed for replies.

A

Anonymous

Eric:
Interesing way of "solving" your problems. Remind me to steer clear of you and your sledgehammer next time I have some walnuts that need shelling ;-)

Sing out when it starts happening again, and we can resume troubleshooting it.

James:
I recommend AGAINST having any updates (windows update, java updates, etc) happening in a live environment *automatically*. I've had bad experiences with automatic Windows Updates actually causing more problems than they solve (and sometimes in the middle of the night, when there's no-one around to fix them), so it's better to perform that sort of maintenance in a way that YOU control, not Microsoft (or - maybe - in this case: Sun).

Cheers.

--
Adam

A

Anonymous

I've seen some interesting statements in this thread some of which are:

> The only time session.navarray is used without array notion
...
> whether it is a string or a number is irrelevant.
...
> the line before the cfapplication tag, it returned that it was an array.
...
> it said strcut in the label on the box (which was now blue)

Obviously, it is very easy to reproduce the error message by using the
code snippets provided, but we are not debugging snippets.

=========== test.cfm ===========

<cfset session.navarray=ArrayNew(1)>
<cfloop index="x" from="1" to="19" step="1">
<cfset session.navarray[#x#]="">
</cfloop>
<cfdump var="#session#" />

<CFAPPLICATION NAME="IREMSite" SESSIONMANAGEMENT="YES">


<cfloop index="x" from="1" to="19" step="1">
<cfset session.navarray[#x#]=x>
</cfloop>
<cfdump var="#session#" />


<cfif isDefined("Session.navArray") AND ArrayLen(Session.navArray) GTE 17>
<cfoutput>IsDefined and ArrayLen > 17</cfoutput>
</cfif>


<cfdump var="#session#" />
=========== /test.cfm ===========

I really do think that you have a real problem. But the most interesting
statement I've seen is this:

> Niether resetting CF or rebooting the server solved it
> this time

Perhaps in CF Admin you should trun off 'Trusted cache', 'Save class files'
and/or 'Cache web server paths'.

Given the behavior seen in the snippet above (run the snippet above),
perhaps you can add a check above each place in the code where
you assign values to the array.

For example:

<cfif NOT IsArray(session.navarray)>
<cfabort showerror="did not get expected type. expected array."
<cfelse>
<cfloop index="x" from="1" to="19" step="1">
<cfset session.navarray[#x#]=x>
</cfloop>
</cfif>

But before that, I think you have already found the problem yourself...

> I narrowed down the change to the cffapplication tag quite simply.
> Using the code described above, on the line before the cfapplication
> tag, it returned that it was an array. After the tag ist returned that
> it was a struct.

The code snippet (test.cfm) above is one illustration of how this is possible.

Good luck!

J

JamesC01

Participating Frequently

Oddly enough I am now having exactly the same problem. I too have not changed the code in this application. Im betting something decided to update itself, like Java.

T

ThreeRavensAuthor

Known Participant

you sure it's not your code *grin*

Let me know if you come with anything. We ended up nuking the server and rebuilding it.

Eric

N

Newsgroup_User

Inspiring

How did you go with this?

--
Adam

N

Newsgroup_User

Inspiring

> described above, on the line before the cfapplication tag, it returned that it
> was an array.

If it did anything other than throw an error, it means you have another
<cfapplication> tag somewhere. There's no problem with this, but if they
have different names, then you'll have completely different session scopes.
With nine years experience in the industry you would know this, though.
But - to humour me - dump out the application scope as well, either side of
the <cfapplication> tag in question, and verify they APPLICATIONNAME is the
same for both.

It might also be worth while checking that in the session scope the CFID
and CFTOKEN values are the same (can't see why it would change just like
that, but it would certainly give you a different session scope.

This raises a point... are any other contents of the session scope
different, either side of the <cfapplication> tag?

Have you checked the CF logs to see if anything dodgy happens around about
when the switch takes place? How about the webserver logs to see if
there's a common theme: some template being exexcuted that you're not
expecting, or something along those lines?

> both instances dumped the contents, except when it was
> an array, the label on the box that displayed it said array (and was that
> reddish/pink color)

This is interesting. What version of CF are you using? For me, when
dumping an ARRAY, it's green. QUERIES are the closest thing to reddish
pink (#AA66AA) for me (CFMX7), on every server I've ever used. Perhaps
you've changed your <cfdump> stylesheet at some point? Or are you using
CF5 (or earlier). I have had only limited experience with CF4.5 and 5, but
know them to be quite flaky when dealing with shared-memory scopes (this is
well documented).

> the isdefined part was working quite fine...the error was on the arraylen
> function.

Sure. isDefined() works *fine*, 99% of the time, with the session scope.
structKeyExists() works 100% of the time. That's all I meant. I don't
like having those wayward 1% worth of potential "unexpected behaviour"
floating around.

--
Adam

T

ThreeRavensAuthor

Known Participant

I put the code...as you suggested at various pints in the code on all the pages included int he request. If it was an array (via isArray) it dumped "array"...if it was a struct (via isStruct()) it dumpt "struct" I narrowed down the change to the cffapplication tag quite simply. Using the code described above, on the line before the cfapplication tag, it returned that it was an array. After the tag ist returned that it was a struct. Whe the cfdump was done on the array...both instances dumped the contents, except when it was an array, the label on the box that displayed it said array (and was that reddish/pink color) and listed the contents in order by element. When it was a struct...it said strcut in the label on the box (which was now blue) and the sort order was by element number...except it sorted by the forst number (ie the 1 in 12) as opposed to the actual number.

Yes, this happened in all sessions. Three of our other developers, plus our client's project manager reported seeing the same problem.

the isdefined part was working quite fine...the error was on the arraylen function.

N

Newsgroup_User

Inspiring

Another question.

Does it happen for ALL sessions simultaneously, or just one session?

--
Adam

N

Newsgroup_User

Inspiring

> offering some suggestions. I did use the debug code and found that the
> cfapplication tag is where the switch happens. No code changes were made on

How did you test that it was the <cfapplication> tag at fault? I mean,
what was the EXACT code you used to test this theory? I ask because I'm
wondering how you could come to that conclusion... the session scope won't
even exist before the <cfapplication> tag, so it's going to be a bit
difficult to say "oh look... here it is changing to a struct, at this line
of code".

And what was the EXACT contents of the struct when you dumped it? (and, to
compare, what SHOULD it have been like)

But here's a thought.

Could some requests be grabbing a different <cfapplication> tag by
accident, and in that application, the session variable in question is a
struct? Not likely given the variable name, I guess.

Do me another favour... change the isDefined() to structKeyExists().
isDefined() has been known to be flaky with the session scope, and return
"false positives". Obviously this should simply cause an error at the next
statement, but I've seen some truly perplexing things with isDefined().

I would offer this advice across the board, not just for this situation.

(This is one of those times CF is at fault, rather than the code ;-)

> COde
> doesn't just do that without some underlying cause.

Precisely. And the cause is almost always user error. Look, if
<cfapplication> had a habit of turning session arrays into structs, don't
you think someone else might have had the problem too?

> If the code was doing it,
> this would be happening 100% of the time,

That doesn't necessarily follow. Not all code is run every request.
Indeed, as this is a session-based issue, there's even more scope still for
some not-oft-run code to mung your data, between requests.

THIS sort of thing: I see all the time. <cfapplication> changing data from
an array to a struct? No, not so much.

> BTW...I have almost 9 years of coding expereince with CF from version 3.0.

Really?

--
Adam

T

ThreeRavensAuthor

Known Participant

Considering that it just switch back to recognizing arrays, maybe I am not the one that needs to get over one's self. How about instead of criticizing me, offering some suggestions. I did use the debug code and found that the cfapplication tag is where the switch happens. No code changes were made on the site and everything "magickally", as you put it, went back to normal. COde doesn't just do that without some underlying cause. If the code was doing it, this would be happening 100% of the time, not randomly switching itself off and on without provocation. The actions of this tell me it's either CF or Windows. BTW...I have almost 9 years of coding expereince with CF from version 3.0.

Eric

N

Newsgroup_User

Inspiring

> At the declaration...it is an array. This code was working fine and sometime
> yesterday afternoon, something happend to cause this error. Nowhere in the
> code is it declared as a struct. The only time session.navarray is used
> without array notion on it (session.navarray) is in isDefined statements.
> This also happened earlier in the week. Resetting CF solved the problem until
> it popped up yesterday. Niether resetting CF or rebooting the server solved it
> this time.

Well, you could stand there saying "there's nothing wrong with my code,
it's perfect, it's CF's fault". Or you could get over yourself and realise
it's far more likely you've missed something, and do something about fixing
it. CF does NOT magically turn arrays into structures. Therefore your
code is doing it.

If you stick the debug code I suggested in, it will go a long way to
tracking down where you're going wrong.

In all my years of using CF (that's only five, but still), here's the
breakdown of whose fault it was when I encountered unexpected behaviour /
bugs in my code:

Me: hundreds.
CF: a handful at best. Two I can think of.

I imagine it's similar for everyone else.

--
Adam

T

ThreeRavensAuthor

Known Participant

Out of the blue, Cf has resumed recognizinging arrays as arrays and not as structs. No clue as to what is causing this. We havn't made any code changes that could ave possibly effected this....

This leads me to believe that someing is amiss in CF in regards to the cfapplication tag.

Eric

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded