It's pretty random. Stack trace is empty so it can't be traced to a particular line. It doesn't happen consistently, nor does it occur during a memory shortage.
Googling didn't reveal anything concrete to work with :( Some suggest it's a symptom, not the root cause. I'd hoped something would show up in the JRun logs, but no.
This is occurring in ACF9 with all the hot fixes I'm aware of.
David Harris
--
You received this message because you are subscribed to the Google Groups "cfaussie" group.
To post to this group, send email to cfau...@googlegroups.com.
To unsubscribe from this group, send email to cfaussie+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
This e-mail is intended only for the named person or entity to which it is addressed and contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure. If you received this e-mail in error, any review, use, dissemination, distribution or copying of this e-mail is strictly prohibited. Please notify us immediately of the error via e-mail to discl...@shift.co.nz and please delete the e-mail from your system, retaining no copies in any media. We appreciate your cooperation.
Yep, given what you’ve said, I’d start to suspect perhaps it’s a concurrency problem, where somehow another thread is clashing with data you’re accessing. These can be knotty to solve, because it’s not always obvious from the code you’re looking at where a conflict could arise. I’m starting to wonder if perhaps the query (that you’re accessing in the Q of Q) might be changing while you’re running the Q of Q. Look closely to see if that’s at all possible.
I wonder, if you were to wrap the Q of Q in a try/catch (and the problem were not so severe that it couldn’t be caught) if you then were to dump the query (being queried), to see what it shows. Maybe you’d see that it was suddenly no longer a query (if some other request overwrote that).
I realize all that’s a stretch, but since you’re grasping at straws (and your first note showed that you had done all the right initial diagnostic steps I would otherwise have recommended), it seems it’s time to start picking the code apart to see if it’s something very subtle. I do think there will end up being something that we go, “ah!” :-)
Finally, if what I’m proposing is the problem, I’d say it would not then seem something that could be spotted any more easily using any JVM inspection tool. I think instead it would just be about data structures within CF, and it trying to access something that is now no longer there, or no longer in the form it expected. But if my suggestion is a dead end, I suppose you could try it. I have found most attempts to dig into the heap have proven time-consuming and generally fruitless, but then I know Kai has done some amazing work with that approach.
Hope that’s helpful.
/charlie
Hmm, I wonder if one could actually see it in the list of thread stack traces in a full heap dump. I guess the thread causing the error would have to be running at the time you'd take the heap dump.
But it's an interesting idea.
I isolated the problem to a QoQ combined with some occasionally bad data.
One of the queries contained un-typed columns. One column contained mainly zeros but occasionally an empty string.
I wasn't joining on this column but I was selecting it.
CF tries to be smart and set a type on the resulting column in the new query. It then barfs when it encounters the empty string.
In this case, garbage in garbage out would suit me fine, but no, it don't work like that!
Thanks everyone for your input, it's probably a CF bug, where an unexpected error happens and CF doesn't produce a proper error for it.
Cheers.