cfdocument hangs

[focused]

We have been generating pdfs for several weeks with no problem. All of the
sudden earlier today, the browser started to hang whenever we get to a
cfdocument tag. Sometimes it works, sometimes the browser hangs. The jrun
process remains at around 40-50% CPU. We have rebooted the server,
stopped/started the CF service. Nothing seems to correct the problem. We tried
with simple 'test' cfdocument files. Still hanging. Anyone else having problems
with page freezing? I'm afraid to move to production if this isn't going to
work reliably.

thanks
Doug

[Hanszon]

Hi Doug,

Had a bit of trouble with this tag myself, discovered that the following will
cause it to hang:

1) Improperly nested HTML tags or block tags (div, p, table etc) not closed,
even though the page may display in the browser.
2) DB query errors - just see a white page, no error message or hint. The
only way to isolate this was to remove the cfdocument tags and output the page
as HTML.

In addition, I have found the poor CSS support causes pages to behave in weird
ways - like truncating overflowing columns when using a "float:left" on a table
instead of flowing onto a second page.

I doubt this is much help because you say you've been generating PDFs for a
while and you tried a simple doc too, but you never know ...

[focused]

Thanks for the info. I just heard of a production server with the same problem
- cpu hung at high usage % and pdf doesn't appear. If they don't get this
corrected...this could become a major problem for them. Were you able to clear
things up by 'cleaning' up the code?

Thanks again.

[Ghost of Rick James]

I am having exactly the same problem. Macromedia... please put this one on the priority list. An acknowledgement that this is a problem would be a great start.

[keihin]

Same problem here. This feature needs to stable if we're going to use it in production.

[rupeshk]

can you post some more details? as in what exactly causes the server to hang? can you take a thread dump when the server hangs and send that to us.

[sdupre]

We really need a stack trace and an example to get started with this.

Technote 18339 shows you how to get a stack trace.

Are you on Windows, Unix?

Please, we want to look at this right away.

Stephen Dupre
Macromedia QA

[steveh1234]

Stephen, my stack trace is below...

We end up with a timeout after the _server_ setting of 60 seconds. The
cfsetting requesttimeout="300" is ignored by the way.

Windows 2003, CFMX 7, 2 CF instances

coldfusion.document.DocumentProcessTimeOutException: The content of this
document process takes more than 60000 milliseconds to process. at
coldfusion.document.DocumentProcessor.ProcessContent(DocumentProcessor.java:127)
at
coldfusion.tagext.lang.DocumentSectionTag.doAfterBody(DocumentSectionTag.java:26
0) at
cfactPrintAppraisal2ecfm1690266858.runPage(D:\webdocs\synapse\tools\business\eva
luation\appraisal\actPrintAppraisal.cfm:59) at
coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152) at
coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:343) at
coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1908) at
cfudfs2ecfm1203561781$funcINCLUDE.runFunction(D:\webdocs\synapse\tools\business\
evaluation\extensions\udfs\udfs.cfm:171) at
coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:348) at
coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:258)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:56)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:211) at
coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:370) at
coldfusion.runtime.CfJspPage._invokeUDF(CfJspPage.java:1765) at
cfindex2ecfm1521540610.runPage(D:\webdocs\synapse\tools\business\evaluation\appr
aisal\index.cfm:165) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152)
at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:343) at
coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1908) at
cfApplication2ecfc1530659078$funcONREQUEST.runFunction(D:\webdocs\synapse\tools\
business\evaluation\Application.cfc:170) at
coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:348) at
coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:294) at
coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:258)
at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:56)
at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:211) at
coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:173) at
coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:192) at
coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:145) at
coldfusion.runtime.AppEventInvoker.invoke(AppEventInvoker.java:55) at
coldfusion.runtime.AppEventInvoker.onRequest(AppEventInvoker.java:116) at
coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:200) at
coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:51) at
coldfusion.filter.PathFilter.invoke(PathFilter.java:86) at
coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:50) at
coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilt
er.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.CfmServlet.service(CfmServlet.java:105) 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$ThreadThrottle.invokeRunnable(ThreadPool.java:426)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

[steveh1234]

More info...

Once we start getting these errors then no cfdocuments will process... all
will return the same error. The cpu starts running up and hangs around 50-60%.
Restarting the CF instance is required to solve the problem.

[rupeshk]

steve,
thanks for the stacktrace. We would also want the thread dump. That will tell
us the status of each thread (and hence the JVM) . that will help us finding
the reason why the cpu is spinning or server is hanging.

Rupesh.

[sdupre]

Can you put together an example? We need the thread dump too but having an
example would be good.

If anyone on this thread can supply an example, please email directly.

Stephen Dupre
Macromedia QA

[steveh1234]

Stephen,

I do not have a reproducable error to give you because it seems that the
problem only happens randomly. Since the documents are genereated from user
entered content, it is difficult to determine if any of what the user enters
could be the problem. The way it works for us, once the error starts
happening, no cfdocuments will process regardless of what is inside them.
Oddly enough, CFML will process fine. So the rest of the application works up
to the document tag.

I've asked our system admin for a thread dump, but it may take some time
before we get one to send you. Hope this helps in the mean time.

Thanks for investigating.

[ricking]

See the following

http://www.ionizedesign.com/sysmex/test_card.cfm

It takes about a minute to generate the PDF. This is the third time this has
occured. The first two times my provider had to restart the server (at least
that's what they told me they did), but it keeps occurring.

This is bad because since it takes so long to generate the PDF, the cfmail tag
is timing out when I try to attached the PDF and email it...

There must be something going on with cfdocument. My code hasn't changed...

[JonesFC]

I was having the same problem and I am about to contact Macromedia to report
the problem wiht ColdFusion CFDOCUMENT tag. Then after doing some tests I found
out that the problem was that if I use an anchor tag ( <A href="filename.cfm">
) to call the cfm file that contains the cfdocument tag everything works fine.
However, when I try to do the same thing calling the cfm file though the action
attribute of a form tag, the page hangs and nothing works. This applies for
using the action attribute to open the file in the same browser or in a new
window by using the attribute Target="_blank".
It seems that the problem has to do with the way the file that contains the
cfdocument tag is being called.
If I get a response from Macromedia I will post here later.

[ARTOSIK]

Hi

Are there any news about the pdf bug mentioned .

Our CF server worked fine producing PDFs then all of af sudden died ? not even
the simplest PDF can be produced now.

I?m just curious if there is any hot fix on the way?

Sik Cambon Jensen
ARTOGIS a/s

[steveh1234]

cul8r,

Just out of curiousity:

1. Are you on standard edition? If so, you may only have one document
generation thread available.

2. Do you see the error message in the log for the error you are causing
inside your CFDOCUMENT tag? We do not see any suspect errors before the hang
up.

Thanks,

[cul8r]

Steve -

1. Yes, I believe we are on standard edition. I don't know if this is a
factor or not but an interesting thought.

2. There is never an error generated with respect to the "hanging PDF" - not
on screen, not in the log. I've tried CFSETTING a parameter in the script for
a 5 second time out on the script - no help.

Chris

[sdupre]

This is bug 61378. CFDOCUMENT issue with CF Standard. If there is an error
inside the <CFDOCUMENT></CFDOCUMENT> tags (you can force one with
<CFOUTPUT>#doesnotexist#</CFOUTPUT> all other CFDOCUMENT templates will pile up
behind. If you get 8 of these, it hangs your server. (all sim request threads
used up).

We expect a hotfix within a day or two (single hotfix) but in the meantime,
one workaround is placing a CFTRY/CFCATCH inside the CFDOCUMENT tag will allow
the template not to block.

<cfdocument><cftry> ..... all the other CFML code ....
<cfcatch></cfcatch></cftry></cfdocument>

To other users on this thread with CF Enterprise, you're looking at a
DIFFERENT problem than this. The symptom is the same (hang) but that's all.
We'll need thread dumps when your system is hung to look into those issues
separately.

The fix for 61378 will do NOTHING for CF Enterprise customers.

Stephen Dupre
Macromedia QA

[steveh1234]

Stephen,

Just out of curiosity, can you explain why this is not an issue on Enterprise?

Also, if anyone comes up with a reproducable error on Enterprise, please post
it. We cannot reproduce this problem. It happens at random.

Thanks.

[Qais]

so what is the solution for bug 61378 ?!! , still can not generate PDF file
after installing the updater, I have 2 servers one with updater and one
without, when I run the same code on each of them, I can generate the PDF on
the one without an updater but can't on the other !!!. How can I uninstall the
updater only ?.

[cul8r]

Any word on when the HotFix will be available? We have to constantly reset the
server whenver there is a single PDF goes off with a glitch in it. We keep
adding additional error checks to the content but we really need it to work
consistently. Reseting the server not only effects that app but every other
app running on the box.

Please also note - the glitch does NOT hang cold fusion. It hangs whatever
process / thread / etc generates the CFDocuments. Other activities on the
server are fine EXCEPT those that try to create a CFDocument type PDF

Thanks !

>This is bug 61378. CFDOCUMENT issue with CF Standard. If there is an error
inside the <CFDOCUMENT></CFDOCUMENT>
>tags (you can force one with <CFOUTPUT>#doesnotexist#</CFOUTPUT> all other
CFDOCUMENT templates will pile up behind.
>If you get 8 of these, it hangs your server. (all sim request threads used
up).
>
>We expect a hotfix within a day or two (single hotfix) but in the meantime,
one workaround is placing a CFTRY/CFCATCH
>inside the CFDOCUMENT tag will allow the template not to block.
>
><cfdocument><cftry> ..... all the other CFML code ....
<cfcatch></cfcatch></cftry></cfdocument>

[sdupre]

We have a patch for this slated for CHF1 (should be released tomorrow).

The bug # is 61378
CF Standard CFDOCUMENT architecture causes CF server hang when all jrpp-
threads (Sim Request) handling CFDOCUMENT calls get in a locked state. (OK in
7.0)

It's possible some of you have a different problem (Esp if you're running
Enterprise so we'd need a thread dump in that case)

Stephen Dupre
Macromedia QA

[sdupre]

This is in Cumulative Hotfix 1 (CHF1) for 7.0.1 and should be published
tomorrow.

61378- CF Standard CFDOCUMENT causes server hangs when all jrpp- threads
handling CFDOCUMENT calls get in a locked state if there is an error in
<CFDOCUMENT>

Thanks for reporting this.

Stephen Dupre
Macromedia QA

[tsongas]

I needed to fix the CFDocument problem but already installed hf70161212.jar
before installing CHF1 for 7.0.1, is this going to cause problems? Should I
remove hf70161212.jar from C:\CFusionMX7\lib\updates since it is included in
CHF1? And will that confuse how the CF administrator keeps track of the
"Update Level?"

Thanks,

Chris

[Sowmya Nayak]

I started encountering this problem only recently. I tried installing the
hotfix, but that didn't seem to help. In fact, now it hangs up every time even
after I restart the ColdFusion service. And the page doesn't even have an
error. Did anybody else have the problem after installing the hotfix?

Thanks,
Sowmya

[Robert Querner]

I have the same problem where pdf generation is impossible. However, on my
development platform (same level of hot fixes), everything works OK. I really
fail to understand this, but I do count on Macromedia providing a solution for
this. One of the reasons for me to move to MX 7 was generation of pdf, but
sofar impossible.:disgust;:o:evil;:o:disgust;

[Robert Querner]

I just found out on another forum, that using images on a secure website
(https) in generating pdf documents, is not possible. I have taken out the
images and now I can correctly generate the documents. I presume Macromedia
will come up with a fix for this bug.
CFMX v7.01 Enterprise

[Jared@Itron]

I am also having this issue but my html seems fine. When i create the table
without cfdocument tags it goes through with no problem. If i then add
cfdocument tags to create a pdf including the table it just stalls forever.

[Robert Querner]

Latest test reveals that generating PDF on https takes infinitely more time than generating the same on http.
This MUST be fixed by Adobe/Macromedia!

[Flemdogg_1]

Does anyone have a workaround for this? I've tried quite a few things I've
found other places with no luck. I'm having the same issue as many as the
posts above. I can't even get a simple PDF to load. It just hangs on a plain
white page.

[sdwebguy99]

Ping to bring this back to the top. I moved a working script to our production
server and get nothing but a hanging page. We have to use FusionReactor to kill
the process.

We have to restart CF to clear the problem--on each of our servers, which is a
real pain. No errors are thrown... just a stack tract for the request that
shows (among other things):

"jrpp-182" prio=5 tid=0x0423d0a8 nid=0x834 runnable
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
- locked <0x1c8ff8d8> (a java.net.PlainSocketImpl)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
- locked <0x1c92a8a0> (a sun.net.www.http.HttpClient)
at sun.net.www.http.HttpClient.(Unknown Source)
at sun.net.www.http.HttpClient.(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
- locked <0x1c932980> (a sun.net.www.protocol.http.HttpURLConnection)

[rupeshk]

Hi Timothy,
1. Are you on standard edition or enterprise? There was a bug in standard
edition where you can have only one thread for cfdocument and if there was any
error in it, all subsequent request will keep waiting.
2. Is it http or https?
3. does it happen every time or randomly? Do you get any error before it
starts stalling?
4. post the entire thread dump or send it to ruk...@adobe.com

Thanks

[rupeshk]

I think my blog entry at
http://coldfused.blogspot.com/2005/11/missing-images-in-cfdocument.html might
help people who are having problems with https.
Could you ensure that your server's certificate is also present in the trust
store.

Thanks,
Rupesh

[Flemdogg_1]

Well, I was finally able to track down what was causing my issues. The PDF I
was generating contained an external stylesheet call and a few images. The
problem was due to the fact the server itself could not resolve the URL to load
the css file or the images. While playing around with it, it seemed it would
finally generate the PDF if I commented out the stylesheet link (with the red X
for the missing images). It seemed to hang for infinity if it couldn't load
the stylesheet. I added some code to force it to use the internal IP address
of the website for all HTTP calls and everything worked like a charm after that.

I would recommend that anyone having problems, start by commenting out the
cfdocument call, to make sure everything loads as it should in raw HTML. If it
doesn't you may be experiencing a similar problem that I had.

Mike

[sdwebguy99]

Rupesh:

We are running CF7.0.1 standard (latest updater, hotfixes). All under http. It
doesnt happen every time -- but whenever it happens (dont know the cause), all
subsequent cfdocument calls fail. It just spins--no visible error is thrown.

How do I get an entire thread dump?

Thanks,
Tim

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

[captainplanet]

We are on standard edition. Without the latest updater, the problem is not happening. When the update is applied, instant problem. It would be nice to have this fixed!

[GoldenJon]

We are also experiencing this problem w/ Standard edition - v 7.0.1

Any progress Adobe?

[GoldenJon]

Please note this problem persists for us after hotfix 2. Anyone still experiencing this problem?

[Sowmya Nayak]

I too am still experiencing the problem on one machine while it works fine on other servers. It's surprising that they haven't come up with a fix for this yet.

[steveh1234]

We still see random cfdocument timeouts from time to time after 60 seconds,
which by the way is not a timeout setting anywhere in our environment. We no
longer seem to have the complete cfdocument hangups that we used to. I believe
they stopped showing up after we installed Updater 2????? We have also removed
any use of FlashPaper generation from our applications due to the IE form
submit bug related to that.

[joaodelima]

Has Adobe released a solution to this problem yet? I am still experiencing it.
Sometimes PDF generation works, sometimes it doesn't. Does anyone know about
any ways to circumvent the problem? Thank you.

[sdwebguy99]

This still doesnt work reliably. Sometimes PDF generation takes 65 seconds to
generate a very simple one page PDF. Latest patches, updates, everything.

Has anyone gotten iText to work on CFMX 7.0.1?

[ad96004]

Hello, evrybody

I have a same probelm with CFDOCUMENT, it seem don't work well in TEXTEREA when have a big text. Hope a new fix.

[PaulH **AdobeCommunityExpert**]

sdwebguy99 wrote:
> This still doesnt work reliably. Sometimes PDF generation takes 65 seconds to
> generate a very simple one page PDF. Latest patches, updates, everything.

i can't see the whole tread in my news reader so just in case, this link might
provide some insight:
http://mkruger.cfwebtools.com/index.cfm/2006/2/16/cfdocument.performance

> Has anyone gotten iText to work on CFMX 7.0.1?

itext drives cfdocument. i use itext a lot for special cases butin general
cfdocument is a better choice for general purpose cases.

[steveh1234]

I just wanted to second or third what a couple of posts mentioned that the
server you are running ColdFusion on must be able to resolve the URL of the
page you are requesting even if all of the code in your CFDocument does not
have any absolute URLs. We beat our heads against the wall for a couple hours
yesterday after moving to a new server and after trying 100 things we
discovered that removing all images, stylesheet link tags, and script tags with
src references, the document would run fine. This led us to realize that on
our old server we had a host file entry for the domain pointing it to the
machine IP address and the new server did not have it. Adding the entries and
restarting CF and IIS fixed it immediately.

[bryced]

We are on running 7,0,2,142559 Enterprise on Unix and have not been able to
create even the simplest PDF before or after the new Update 2.

A page with the code,
<cfdocument format="pdf">content</cfdocument>
hangs indefinately.

Refreshing the page several times does crash the server as described in an
earlier posting.

The pdf page does not work after restarting the server, even the first time.

I have searched the forumns and the net for a solution but have yet to find
one. Has anyone successfully resolved this issue?

[Ryan Bergman]

We had the same issue on 7,0,2,142559. I found this fix on another site and it
worked for us as well:

---------------------
1) Stop all CFMX7 services

2) Browse to C:\CFusionMX7\wwwroot\WEB-INF\

3) Be sure you have a folder inside this called "cfclasses_backup" (and with
files in it)

4) Delete all files in the "C:\CFusionMX7\wwwroot\WEB-INF\cfclasses"
directory.

5) Restart all your CFMX7 services. This will recompile all the classes into
the directoy you just deleted them from.

6) Make sure you can surf to and open CFMX admin.

7) Try your Cfdoc tag - worked for me.

Apparently, when 7.0.1 is installed it's supposed to remove all the old class
files, and recompile the new ones in the "cfclasses" folder.

Then the cfclasses_backup receives the old files during the patch upgrade. For
some reason, unknown to me,
the class file overwriting/updating doesn't work correctly during the patch
upgrade. But it did solve the problem for me.

[pedromorin]

I'm having a similar problem with cfdocument. I'm creating a dynamic PDF that
writes to a file (using filename="#pdf#"). Although it's slow, it does
eventually create the pdf. That's when my problem begins. I see the pdf on the
server, open it, and it looks fine. However, the page that created the pdf is
still running and will not stop until I click the browser "Stop" button. This
creates a problem because I'm trying to redirect the user to another page after
it creates the PDF. What can I do to make the page stop running after it
created the PDF?

Any help would be greatly appreciated, thanks.

[Kart.no.338]

I realise that this topic is old but I have searched the internet and cannot
find an answer to my question.

Hopefully someone here can provide me with one?

Anyway, is it possible to send an email with a <cfdocument> in it?

I have tried simply doing <cfmail><cfdocument>XX</cfdocument></cfmail>
examples but when you run the page it doesnt email the file it just tries to
open the document in the browser.

Is there any work around?

[Robert Querner]

You should first write the document to the disk:
<cfdocument format="pdf" filename="#filename#.pdf">

Then email the document with cfmail as an attachment:
<cfmail mimeattach="#filename#.pdf">

That should work.

[Kart.no.338]

[q][i]Originally posted by: [b][b]Robert Querner[/b][/b][/i]

That should work.[/q]

Thank You very much

[EmmanuelRuiz]

Has anyone got a timeout issue with cfdocument/itext. Seems now that cf crashes as soon as we are trying to generate a pdf file larger than 14mb. seems like a thread issue. Any ideas?

[obouillaud]

Still many errors (7.0.2 entreprise), randomly.
Exactly like the others, when the problems occurs, no more PDF could be
generated until we restart CF.
There is lots of images in my documents, but I dynamicaly replace all img src
by the URL of the local server (192.168.x.y instead of www.mysite.com for
example)

Error : The document has no pages. null

StackTrace 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
cfbook2ecfm1292925959.runPage(\\10.1.17.243\microapp\ma_externe\revendeur\module
s\book.cfm:210) 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
cfindex2ecfm2060449212.runPage(\\10.1.17.243\microapp\ma_externe\revendeur\index
.cfm: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(ClientScopePersistenceFilt
er.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)

[rgurganus]

In response the "document has no pages" error, I just wanted to repeat what was
said above about checking the HTML coding. After getting this error, I copied
the browser source back to an HTML validator and found a lot of minor warning
errors that weren't causing any display problems, but apparently were the cause
for the CFDocument error. As soon as I cleaned the coding problems, the PDF's
starting coming through immediately and no errors.

[jbreslow]

This solved our issue. We were getting the document contains no pages error...

http://kb.adobe.com/selfservice/viewContent.do?externalId=fc4b2de9

Perm. Link:
http://www.adobe.com/go/fc4b2de9

ColdFusion MX: Using cfdocument on Unix platforms
Issue

The cfdocument tag might cause the following error when running ColdFusion MX
on a Unix platform: ExceptionConverter: java.io.IOException: The document has
no pages.

The following error will also appear in the standard error log file:

When the format is FlashPaper:

java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at java.awt.Toolkit$2.run(Toolkit.java:748)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:739)
at ice.pilots.html4.FontCache.init(OEAB)
at ice.pilots.html4.FontCache.<init>(OEAB)
at ice.pilots.html4.StormData.<init>(OEAB)
at ice.pilots.html4.StormData.get(OEAB)
at ice.pilots.html4.ThePilot.init(OEAB)
at ice.storm.StormBase.append(OEAB)
at ice.storm.StormBase.do_clear_content(OEAB)
at ice.storm.StormBase.do_render_content(OEAB)
at ice.storm.Viewport.runAsynchronousLoad(OEAB)
at ice.storm.LoadThread.run(OEAB) Caused by: java.lang.NullPointerException
at sun.awt.motif.MToolkit.<clinit>(MToolkit.java:81)
... 15 more

When the format is PDF:

java.lang.NoClassDefFoundError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at java.awt.Toolkit$2.run(Toolkit.java:748)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:739)
at ice.pilots.html4.FontCache.init(OEAB)
at ice.pilots.html4.FontCache.<init>(OEAB)
at ice.pilots.html4.StormData.<init>(OEAB)
at ice.pilots.html4.StormData.get(OEAB)
at ice.pilots.html4.ThePilot.init(OEAB)
at ice.storm.StormBase.append(OEAB)
at ice.storm.StormBase.do_clear_content(OEAB)
at ice.storm.StormBase.do_render_content(OEAB)
at ice.storm.Viewport.runAsynchronousLoad(OEAB)
at ice.storm.LoadThread.run(OEAB)

Solution

Remove the
java.arg-Djava.awt.graphicsenv=com.gp.java2d.ExHeadlessGraphicsEnvironment and
replace it with -Djava.awt.headless=true in the jvm.config file. In the single
server installation, the jvm.config file is found in the cf_root/runtime/bin
folder. In the J2EE or multiserver installation on JRun, the jvm.config file is
found in the {jrun-root}/bin folder.