CFDocument Errors And Resolving DNS

Posted September 13, 2006 at 9:23 AM

Tags: ColdFusion

I was trying to get a printed report working for a client using the CFDocument tag. Everything worked fine on the development server, but then broke when uploaded to the production server. Initially, we were getting the following error:

An exception occurred when performing document processing. The cause of this exception was that: coldfusion.document.DocumentProcessTimeOutException: The content of this document process takes more than 20000 milliseconds to process.

The report was really small but did contain HTML markup. As a test, I tried to run it in HtmlEditFormat() to see if the HTML rendering might be causing problems. Yes it was. When converted to text, the CFDocument tag worked just fine.

To try and fix this issue, we installed all the ColdFusion Hot Fixes. This was a new production box (for a single client) and had not been fully updated. After installing the updaters, the above error was fixed, but just replaced with this new error:

The document has no pages. null <br>The error occurred on line 55.

... with a stack trace of:

The document has no pages?? What the hell is that? After about 45 minutes of commenting out different parts of the HTML and putting things back in, and taking them out again, I finally narrowed down the problem code. It was an image header. The SRC of the image tag was a fully qualified URL to the web site that the production box was hosting.

Obvious problem? Not at all. Servers aren't my thing, so I would have NEVER gotten it had my boss, Jim Curran, not known so much about servers. Apparently the problem has to do with the server trying to resolve the DNS. The way he explains it is that CFDocument had code that called the web. The server then went out of the box to the router at the hosting company to ask for the DNS information. The router then told the server that the DNS resolved to the IP of the very box that was the requesting server (since the server hosted the web site). This apparently blew up in the server's face because this is something known as "Route Back", which I guess is blocked by default. So basically, the server was not being allowed to grab the Image source at the specified URL, the CFDocument tag couldn't handle this (and wouldn't even show an X'd out image), and the page totally crashed.

Now, again, I don't know server stuff, so I don't really know the next step. But, basically my boss fixed this by updating the host file??? on the server that overrides the DNS from the router. As he explained it, the server checks this file first, and now, since there was an entry that said a specific Domain was actually the internal IP address of the server, the server no long went to the router, Route Back was not an issue, and the server could grab the URL data.

So, I am sure some of that is unclear (as it is to me) and perhaps just plain wrong. But, we finally got it fixed.

Post Comment  |  Ask Ben  |  Permalink  |  Other Searches  |  Print Page

• Add To Del.icio.us
• Add To Digg
• Add to Spurl.net
• Add to Wists
• Add to Simpy
• Add to Newsvine
• Add to BlinkList
• Add to Furl
• Add to reddit
• Add to FARK
• Add to BlogMarks
• Add to Yahoo! My Web
• Add to smarking
• Add to Ma.gnolia
• Add to Segnalo

Reader Comments

It's a fairly common networking mistake. (I'm sure someone will try to yll at me and tell me that they are doing it on purpose, but whatever.) It's especially common in DMZ situations (your web servers live on their own subnet that has a different set of rules for your firewall/router) than the rest of your intranet does. If your intranet has one DNS server on the inside and your DMZ servers can't see that internal server and are instead relying on the public DNS server, things can get a bit hinky.

General flow:
You: Firefox, give me a PDF of the home page of foo.com.
Firefox: DNS, where is foo.com?
INTERNAL DNS: Foo.com is sitting in the DMZ at 192.168.52.2.
Firfox: Foo.com, gimme a PDF of your home page.
Web Server: One sec while I build it ... Okay, I need an image from www.foo.com. DNS, where is www.foo.com?
PUBLIC DNS: Foo.com is on the Internet at 62.63.64.65.
Web Server: Router/Firewall, connect me to 62.63.64.65.
Router/Firewall: Um, no. That would just be dumb. If you are on THAT side of the fence you need to talk to people on YOUR side only. Oh, and you ARE that address, n00b!
Web Server: No I'm not! I'm 192.168.52.2! kaboom!
Firefox: Dude. WTF?

Exeunt.

"n00b!" HA HA HA HA

That's hillarious :) Thanks for quality mixture of explanation and comic relief.

Hi -

I'm getting that same error for a pdf which is +100 pages and between 3 and 12 fields. I set the requesttime=2000 with no help? I am using cfmx 7.0.2 w/patches enterprise version. WHY??? Any help would be appreciated. Does requesttime work at all for cfdocument at all????

Pat

Pat,

I would suggest taking out any references to things that are URL based (ie. CSS files, Images, etc). Then run the document again to see if it works. If that is the case, then it might be a DNS issues. If it still crashes, then it might be a new error all together.

Let me know what happens.

Pat,

I am not sure how the RequestTimeOut transfers over to CFDocument. Sorry.

Thanks for the post, solved my problem also. Big Thanks.

Ben -- adding another shout out that this just helped us resolve the same problem in our PROD environment. Thanks for taking the time to post...

I'm getting the exact same error running the following code:

<cfdocument format="pdf">
<h1>Hello World!</h1>
<p>Hello everyone!!!</p>
</cfdocument>

That is the entire contents of the body tags. And I am getting the error in a couple of apps that were working fine up to now??

@ldr041,

It seems odd that this document would throw an error if it has no code that is making references to URLs! Crazy!

Post Comment  |  Ask Ben

Post A Comment

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Formatting: <strong>bold</strong> <em>italic<em>
	Remember my information
	Subscribe to entry *
	Send me a copy of this comment (as part of the comment thread)

 

* If you subscribe, any new posts to this thread will be sent to your email address.