Skip to main content
E
ej401
Inspiring
April 13, 2021
Answered

CFHTMLTOPDF Fails After Restarting Services

  • April 13, 2021
  • 3 replies
  • 4773 views

Since installing CF 2021 HF 1, we have had issues with CFHTMLTOPDF after a service restart. The error in the application log after trying to generate even a simple PDF is:

 

Error occurred while generating PDF.Reason: SERVER ERROR

 

The stacktrace is:

 

58472 "Error","cfthread-3","04/08/21","14:38:11","","GENERATEPDFS: Error occurred while generating PDF. Reason: SERVER ERROR"
58473 coldfusion.document.webkit.PDFgErrorHandler$ServiceManagerConversionException: Error occurred while generating PDF.
58474 at coldfusion.document.webkit.PDFgErrorHandler.handleConversionError(PDFgErrorHandler.java:190)
58475 at coldfusion.document.webkit.HttpPDFRequestHandler.requestPDFGeneration(HttpPDFRequestHandler.java:178)
58476 at coldfusion.tagext.htmltopdf.HtmlToPdfTag.processPDFgRequest(HtmlToPdfTag.java:1149)
58477 at coldfusion.tagext.htmltopdf.HtmlToPdfTag.handlePDFgConversionRequest(HtmlToPdfTag.java:1299)
58478 at coldfusion.tagext.htmltopdf.HtmlToPdfTag.convertToPDF(HtmlToPdfTag.java:1236)
58479 at coldfusion.tagext.htmltopdf.HtmlToPdfTag.doEndTag(HtmlToPdfTag.java:1412)

 

And the error in the server log is:

 

Read timed out http://127.0.0.1:8993/PDFgServlet/

 

After the above server error appears, the only way to correct the issue is to stop the "localhost" PDF service manager, edit and save it, and then restart it. If you only stop and restart it, the issue is not fixed. In terms of the messages in the server log, stopping the PDF service generates:

 

PDFg service manager http://127.0.0.1:8993/PDFgServlet/ unregistered.

 

But we don't see the corresponding "registered" message until after an edit AND restart:

 

PDFg service manager http://127.0.0.1:8993/PDFgServlet/ registered.

 

At this point, the service starts working again and PDFs can be generated.

 

Thoughts or suggesions?

 

Thanks,

Eric

    This topic has been closed for replies.
    Correct answer Charlie Arehart

    I realize this is a couple years on from the original post, and I know EJ offered as the "answer" his identification of the need for him to change things so that the Add-on services always starts before the CF service.

     

    That said, some people get this error when the error when instead CF is already RUNNING and they have some reason to restart the add-on service (or somehow it restarted). And in that case, while restarting CF ALSO could help, obviously that's not desirable if this is prod and you don't want to restart CF just then.

     

    So to that, I want to draw attention to a workaround that EJ actually offered in the original post. It's not identified as an "answer" but it does seem it should be:

     

    "[a] way to correct the issue is to stop the "localhost" PDF service manager, edit and save it, and then restart it. If you only stop and restart it, the issue is not fixed."

     

    And to be clear, what EJ means about "stopping" the "service manager" is not stopping the Add-on service. Instead, EJ means in the PDF Service tab of the CF Admin, you should find one of those "services" listed to be "localhost" (which you can't remove).

     

    And assuming that this is indeed THE service you are wanting to use, EJ was saying to click the "stop" icon to the left of the service, then click the "edit" button for it, and without even making any change, click the "Update PDF Service Manager" on that page, then click the "start" button for the pdf service. Now finally try using the "verify" icon on the PDF service page. Does it now verify? It has for me and others in this situation (where the only problem was that the add-on service had been restarted for some reason, while CF was running).

     

    Then try testing your page DOING the cfhtmltopdf: does it work? If not, don't forget to click the "start" button.

     

    As an update (on 3/29/23) since I originally posted this comment, I have found I don't even need to do the stop/start of the pdf service. Just click the "edit" button for the service, then click the the "Update PDF Service Manager" on that page (without even making any change). I have found that then PDFs start working. I'll offer another comment with some adminapi code you could call to do this in a more automated fashion.

     

    Again, all this is just a WORKAROUND. I realize it's not optimal. And we should be able to find what it is causes things to "work again" once we do this simple operation. I've not yet had time to dig into that. But as I see this question (of this error) come up again and again--and some lament that "they can't control the order or services starting", etc--at least they will hopefully be able to try this one simple workaround, which doesn't require any restarting of any services.

     

    Finally, as for other problems with the add-on service not working, I will note that sometimes the solution there has to do with the JVM that was configured in the jetty.lax (in the cfusion/jetty folder), and perhaps a need to change, update, or downgrade that. This goes way beyond the scope of THIS post, so I will leave it at that, if it may help anyone. Or you can reach out via my site (signature below)to look into that more.

    3 replies

    Charlie Arehart
    Charlie ArehartCorrect answer
    Community Expert
    March 22, 2023

    I realize this is a couple years on from the original post, and I know EJ offered as the "answer" his identification of the need for him to change things so that the Add-on services always starts before the CF service.

     

    That said, some people get this error when the error when instead CF is already RUNNING and they have some reason to restart the add-on service (or somehow it restarted). And in that case, while restarting CF ALSO could help, obviously that's not desirable if this is prod and you don't want to restart CF just then.

     

    So to that, I want to draw attention to a workaround that EJ actually offered in the original post. It's not identified as an "answer" but it does seem it should be:

     

    "[a] way to correct the issue is to stop the "localhost" PDF service manager, edit and save it, and then restart it. If you only stop and restart it, the issue is not fixed."

     

    And to be clear, what EJ means about "stopping" the "service manager" is not stopping the Add-on service. Instead, EJ means in the PDF Service tab of the CF Admin, you should find one of those "services" listed to be "localhost" (which you can't remove).

     

    And assuming that this is indeed THE service you are wanting to use, EJ was saying to click the "stop" icon to the left of the service, then click the "edit" button for it, and without even making any change, click the "Update PDF Service Manager" on that page, then click the "start" button for the pdf service. Now finally try using the "verify" icon on the PDF service page. Does it now verify? It has for me and others in this situation (where the only problem was that the add-on service had been restarted for some reason, while CF was running).

     

    Then try testing your page DOING the cfhtmltopdf: does it work? If not, don't forget to click the "start" button.

     

    As an update (on 3/29/23) since I originally posted this comment, I have found I don't even need to do the stop/start of the pdf service. Just click the "edit" button for the service, then click the the "Update PDF Service Manager" on that page (without even making any change). I have found that then PDFs start working. I'll offer another comment with some adminapi code you could call to do this in a more automated fashion.

     

    Again, all this is just a WORKAROUND. I realize it's not optimal. And we should be able to find what it is causes things to "work again" once we do this simple operation. I've not yet had time to dig into that. But as I see this question (of this error) come up again and again--and some lament that "they can't control the order or services starting", etc--at least they will hopefully be able to try this one simple workaround, which doesn't require any restarting of any services.

     

    Finally, as for other problems with the add-on service not working, I will note that sometimes the solution there has to do with the JVM that was configured in the jetty.lax (in the cfusion/jetty folder), and perhaps a need to change, update, or downgrade that. This goes way beyond the scope of THIS post, so I will leave it at that, if it may help anyone. Or you can reach out via my site (signature below)to look into that more.

    /Charlie (troubleshooter, carehart. org)
    Charlie Arehart
    Charlie Arehart
    Community Expert
    March 29, 2023

    As a follow-up to my last comment, I want to share that I've since put together some CFML using the CF "admin api" that would allow one to do this reset of the PDF service (without needing to do the "edit and save" of it, discussed in my last reply).

     

    About this code, note a couple of things before "just running it":

    • Of course, to run the Admin API one has to know the CF Admin password--and you need to either hardcode it in the login call below or tweak the code to pull it from a variable. I realize that makes this a show-stopper for some
    • Note that the code below presumes to reset the PDF service with the NAME of "localhost" and is setting its "values" to be the same as they are by default, "127.0.0.1" and "8993" and "2" (for the "weight"). If your values are different, of course you need to change the code to use YOUR values. (And yes, one could evolve the script to pull out your current values and use those instead.)

    Here's the code:

     

    <cfscript>
// Login is always required. 
adminObj = createObject("component","cfide.adminapi.administrator");
adminObj.login("yourCFadminpw");
docObj = createObject("component","cfide.adminapi.document");
// change the args as needed to match your CF Admin settings
docObj.editServiceManager ( "localhost", "127.0.0.1", 8993, 2, "no" );
</cfscript>

PDF manager reset

     

     

    Of course, one benefit of this code approach is that it could even be setup to be called from an error handler which detects that the pdf service is not working.

     

    (Or I had someone pose they would run a sched task each night to do it--but that would leave it not working for quite some time between when it stopped working and when this would reset it, but I guess it's better than it being down for days. There should be no negative impact of resetting it, though I suppose if a PDF creation request was in the midst of running. Again, my proposal was to use it when the pdf service was not working.)

     

    I'd love to hear how it goes for folks. 

    /Charlie (troubleshooter, carehart. org)
      C
      Casey.Dougall
      Participating Frequently
      March 31, 2023

      Has someone added this as a bug? this only started happening for me after CF2021 update 6.

      P
      Pierre23682963n3yh
      Participating Frequently
      November 3, 2022

      Great and useful findings, I had exactly same issue and "Edit and restart" of service manager has solved it.

      Thank you ! 

      E
      ej401Author
      Inspiring
      April 15, 2021

      Update: we changed the order of how we restart the services (pushing the PDF service to the beginning) and this appears to have solved the issue. There is still a PDFgServlet timeout error after all of the services are restarted, but initiating a PDF job after this automatically registers the service and all is well.

      K
      karih38190410
      Inspiring
      May 26, 2021

      Thank you ej401...I have the same exact problem and your solution works.  I'm not excited about having to restart the whole CF in order to get it to recognize a pdf service.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices