Reputation: 1619
This morning I ran into some issues using the cfdocument
tag. When a user runs a report, the report just hangs. The report has been running for years with no issues. I even took all of the code out and just put in the following.
<cfdocument format="PDF">this is a test</cfdocument>
The browser still hangs, no errors and the CPU does not jump. I am not sure why this does not work. Any suggestions?
Upvotes: 0
Views: 1204
Reputation: 6894
Here's a very real possibility for your hanging cfdocument: are you running the ColdFusion Standard edition license?
If so, you probably had another request running that was ALSO doing either a cfdocument or any of several other CFML tags which are single-threaded (with each other) in that edition. If such another request was running long--taking a long time to do a cfdocument itself, for instance--then that will have held up even this simplest cfdocument test you had. And tour restart of CF killed that other long-running request, thus allowing yours to run as expected.
(I realize this question is several years old, and the asker may have moved on long ago. I am offering this now as much for others who may find/have the same question.)
To clarify, starting with CF8, Adobe implemented something called the Enterprise Feature Router--in the ColdFusion Standard edition license. It does NOT apply to the ColdFusion Enterprise or free Developer or Trial editions. With the EFR, all requests that use any of several documented features are single-threaded: only one request at a time can run ANY of those features.
Adobe never documented the tags, but they list several "features" which show being "restricted" in a column of the CF Buying Guide document. See the paragraph below the table of features, which says:
Restricted features in ColdFusion Standard Edition: Enterprise features run through the Enterprise Feature Router (EFR). These features run in the Standard edition. However, all features running through the EFR are limited to one shared simultaneous request.
Among the most common tags (or their script equivalents) where people hit this issue are indeed CFDOCUMENT, and another is the related CFHTMLTOPDF. Still others are less-used: including CFPRINT and CFPRESENTATION. And while the buying guide refers to "pdf manipulation" as one of the "restricted" feature, in have not found any of the many CFPDF tag's actions to be EFR-limited.
Bottom line: if any one request takes a very long time to run--while running ANY such a "restricted" tag--then that request will hold up ANY OTHER requests trying to run at the same time, if those requests also try to run ANY of these "restricted" tags.
Upvotes: 0
Reputation: 26
I had a bunch of programs that included file:/// in a cfdocument tag.
I had thought that the file reference would be more efficient, however under coldfusion 2016, it caused occassional, unpredicatable server hanging.
The cfdocument process moves all required files into a work folder, and then produces the pdf.
In CF 2016, there is a setting (Clear Temporary Files Created During CFaaS after (Minutes) that by default clears out work files older than 30 mins.
However, if you use the file:///, then the creation date of that file is not reset, and when that process runs it will delete the file immediately - it is always older than 30 mins.
If the cfdocument process is half way through processing, and it collides with the Clear Temp File process, then a required file disappears, and cfdocument just hangs.
Then subsequent programs with a call to cfdocument also hang, as only one is allowed to execute at any one time.
This then eventually fills up all the cf processing slots, and required a restart of cf to get things going again.
Upvotes: 1
Reputation: 354
Adobe ColdFusion has been known to have bugs wherein an error in the code (e.g. improperly nested HTML tags not closed, DB query errors, invalid variable) inside the <cfdocument></cfdocument>
can silently fail without showing an exception. When this happens, all other cfdocument
requests will pile up behind. This can happen even when other pages, not using cfdocument
, finish just fine.
As you have seen, restarting the CF service also restarts the PDF service and clears the 'pileup'.
The solution is to debug the code inside the cfdocument
tag so that it doesn't throw an exception. Since your issue sounds intermittent, that can be really difficult to debug. You could put everything inside the cfdocument
inside a cftry
, then cfcatch
any exceptions and email them to yourself.
Upvotes: 1