CFDocument Errors And Resolving DNS
Posted September 13, 2006 at 9:23 AM by Ben Nadel
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:
ExceptionConverter: java.io.IOException: The document has no pages. at com.lowagie.text.pdf.PdfPages.writePageTree(Unknown Source) at com.lowagie.text.pdf.PdfWriter.close(Unknown Source) at com.lowagie.text.pdf.PdfDocument.close(Unknown Source) at com.lowagie.text.Document.close(Unknown Source) at coldfusion.tagext.lang.DocumentTag.doAfterBody(DocumentTag.java:1225) at cf_print2ecfm2102830720.runPage(....:55) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:349) at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1915) at cf_index2ecfm1113080573.runPage(....:16) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:349) at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1915) at cfve_reports2ecfm515217088.runPage(.....:32) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:349) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:225) at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:51) at coldfusion.filter.PathFilter.invoke(PathFilter.java:86) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:69) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter.java:115) at coldfusion.CfmServlet.service(CfmServlet.java:107) at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:78) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:257) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:541) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:204) at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:318) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:426) at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:264) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
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.
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!
I am also working on creating invoices for customers and had similar problems, but my problems were related to adding IMAGE SCR directly from same server, same directory. Anytime I include the image, it would take forever to generate PDF file and it will not load image, it will be an empty box.
Someone told me it is related to SSL certificate in IIS, but i am able to browse any other page on the site with no problems.
I also imported SSL cert to Coldfusion's cert directory using command line and keytool.
Any idea why it will still no load image?
Or how does CF 8 interact with SSL Cert applied to IIS
@Ghaleb,
It might be the same routing issue that I was having? I don't know too much about sever setup, but did you try the route back stuff?
I would love to have a similar thing to cfdoc tag for other files like .csv files.
I'm feed up ending up with lots of files on my server that I need to clean up.
You know any workaround?
@Nikos,
I am not sure what you mean?
This was what I wanted to do:
<cfsavecontent variable="test">
test csv content
</cfsavecontent>
<cfmail from="test" to="test" subject="csv attachment test">
<cfmailparam disposition="attachment" file="testDoc.csv" type="text/csv" content="#test#" >
mail content: blah blah
</cfmail>
thanks
Guys I had a issue today in that when I uploaded an invoice document to the production server all sorts of error messages kept appearing "An exception occurred when performing document processing.
The cause of this exception was that: coldfusion.tagext.lang.DocumentTagException: An exception occurred when performing document processing.." after reading this post and commecting all my html out of the page I then realised this file was trying to be saved on the server in a directory that does not exist so hence the error message, I created the directory and bang it works fine. Adobe please can we get some "Friendly error messages" TA
@Nikos,
Ah, now that I see what you're doing, you can actually do that now with CFMailParam using the "Content" attribute. The Content attribute allows you to attach binary information to the email without going to the file system:
http://www.bennadel.com/blog/1220-ColdFusion-CFMailParam-s-New-Content-Attribute-Is-Awesome.htm
I hope that helps.
@Mark,
Yeah, you will definitely come across some error messages that lend no insight at all. One of my personal favorites is the "null null" error.... that's all you get... "null null". Awesome :)
Rupesh Kumar's workaround solved the issue for us:
http://coldfused.blogspot.com/2006/09/workaround-for-cfdocument-missing_19.html
As a FYI we had a different problem (I hope). It appears that there is also an issue where cfdoc can blowup if you have "<br /><br />". Who knew?!!?! Friggen worst issue to try and track down.
http://www.mximize.com/java-io-ioexception-parsing-problem
