XMLParse Crashing Jrun

[RVonDrunkpants]

Greetings, I'm having an issue with XMLParse.

When I try to XMLParse something that isn't XML (such as a 404 error) instead of getting an error, the Jrun hangs at around 6% of processor and the whole system locks up.

I know in the past, XMLParsing non-XML resulted in a ColdFusion error instead of a complete lockup - what happened, and how can I get my CF error back instead of a complete server freeze?

Specs:

Coldfusion 8,0,1,195765

Standard  Edition (32-bit)

Java Version                                                      1.6.0_22 

Adobe Driver Version                                                      3.6 (Build 0027)

Windows Server 2008 (64-bit)

Service Pack 1

6GB RAM

2x XEON E5540 @ 2.53GHZ

[meensi]

Hi,

Whats the size of your XML?

We had the problem of JRUN Crashing when we use XMLParse() for parsing a big XML. we tried to split the XML and change the JVM version from CF to JAVA. things worked good.

I dont remember exactly, but we did used CFTHREAD.

[BKBK]

You could, before applying xmlParse(), use the method isXml() to first test whether the string is well-formed XML.

[RVonDrunkpants]

I've started using cfif isXML() around my xmlParse tags - but that doesn't address the underlying cause of why it's crashing ColdFusion instead of just returning an error that I can trap.

That, and there are well over 1000 instances of xmlParse on the server - and I can't fix all of them.

[Adam Cameron.]

Is it any non-XML that causes this, eg:

x = xmlParse("not XML");

?

Does anything go into either the CF or JRun logs when this is happening?

What parameters are you using with xmlParse(), eg: are you doing validation as well, or just a parse?

--

Adam

[RVonDrunkpants]

@Adam - pretty much. I'll give you an example:

Let's say I do a CFHTTP out to get an XML file on a web server, and for whatever reason, that XML file does not exist.

If I go to xmlParse() a file that does not exist and I get back a HTML 404 error, CF will immediately hit 6% processor usage and then stop working altogether.

Do not pass GO, Do not collect $200 - it will completely freeze. It won't tell me that what I'm trying to xmlParse isn't XML, it just locks.

I've started wrapping things in <cfif isXML(cfhttp.filecontent)> but that will only go so far.

I seem to recall at some point in time that if I tried to xmlParse garbage (or in this case, a 404), that it would tell me that what I was trying to parse wasn't XML and it would give me the regular CF error.

[Adam Cameron.]

@Adam - pretty much.

"pretty much" or "yes"?

My exact code - as cited above - what happens when you run it?

--

Adam

[RVonDrunkpants]

@Adam - I'll have to get back to you on that.

I just started a new job this week and I'll have to get someone at my last job to try to run it.

The server crashing issue was something I was trying to resolve before leaving, so that I wouldn't leave an unstable CF server for someone else/new to deal with.

[StevenErat]

Generate a thread dump while the problem is occuring (via "normal" means of

generating thread dumps, or by using the Server Monitor feature for creating

a "snapshot" - A snapshot contains a full thread dump in addition to other

good info about what the server is doing internally).

The actual java thread stack will show you precisely what's going on.

Moreover, take a couple thread dumps or snapshots about 30 seconds apart

then find the problem stack in each one and compare them. That would tell

you if the thread is literally "stuck" on something or not (if the thread

stack is unchanged between the two).

[RVonDrunkpants]

@Steven -

I'll have to try this, thanks.

http://www.bpurcell.org/blog/index.cfm?mode=entry&entry=1062