The subject is the best way I can summarize up the issue. The following contains a list of my findings/observations over 6-8 hours of trying to get EO.PDF deployable for our product.

EO.PDF / environment:
- Last publicly posted EO.PDF build (4.0.60.2) with active license.
- ASP.NET 3.5 / SharePoint 2010 / Impersonation - code is running in ASPX page.
- HtmlToPdf.ConvertUrl is being used to process a complex page (Knockout JS + Durandal SPA) that uses Manual triggering mode.
- NoCache is true; however, neither true nor false affect the observed behavior.

Here are what I have observed ("WORKS" means that the JavaScript on the page appears to be executed and the page is rendered correctly; anything else means that it either timed out or appeared to not process the JS at all):

The first time a worker is spun up, it ALWAYS WORKS. Restarting the IIS worker process results the conversion working. Likewise, calling EO.PDF from a new process (a test executable) appears to always work. After the first time, failure (see below) rate appears to be 50-70%. It will still "occasionally still work" and appears to have a higher chance of working when a new worker is created.

When the worker processes/queue starts failing it appears as if NO JAVASCRIPT IS BEING EXECUTED. Consider these observations:
- When reverting back to Auto mode with a "lengthy min load time" the Page is rendered as though no JS was executed (Durandal SPA never opens initial view)
- window.onerror is registered to cause eopdf.convert - this does not occur
- a setTimeout is registered to cause eopdf.convert - this does not occur
- no output from console.log is reported on DebugConsole

Also, killing the host process while EO.PDF is processing can lead to a RUN-AWAY worker process that increases memory usage by several MB/second and will eventually consume all resources. I am not sure what the exact trigger is, but I have seen this 4 times during abrupt restarts. Not good for a server.

== WORK-ABOUT ==

What makes it ALWAYS WORK (and is the work-about hack currently being used):

Creating a new AppDomain, running the EO.PDF conversion in there, and then Unloading the AppDomain ALWAYS WORKS. This indicates that there is an issue related to the persisted queues/workers. This is likely related to the above observation that it always works on the first request given to a new worker process. (I hypothesis that it is the queueing system and/or residue or bad connections left from a previous page rendering; but having already invested a significant amount of time isolating the issue and deriving a work-about, I am doing investigating this matter.)

However, the hack listed about is icky and incurs longer process spin-up times - in the immediate case it is not the issue and I can afford to have the user waiting an additional 5 seconds for a print result (as opposed to waiting forever for a timeout or a long time for an incomplete generation), but the current approach to the workers/queues needs to be investigated.

I would like to see a "more robust" queue pattern used (even if I must manually manage lifetimes/pools with IDisposable or similar, that's fine!) - reading around in other posts it seems like worker "lifetime management" is currently a brittle component that can exhibit other issues as well.

Has there been any updates on this? I think I'm running across this same issue. Just wondering if I need to go the same route to create a new app domain or not.

In my case, I'm using the HtmlToPdf.ConvertUrl() method, passing it a url to a single page app html file that uses javascript for routing and loading. I'm calling it several times to the same html page, but different routes, example:

.../mypage.html#generatePDF/3/2
.../mypage.html#generatePDF/3/4
.../mypage.html#generatePDF/3/6

The first call always works, but the other calls appear to randomly work, similar to the original issue in this post.

Thanks.

Hi,
I'm not sure if what I am experiencing is exactly the same, but it is very similar. I am generating a PDF with a google map, though I am using HtmlToPdf.ConvertHtml, with html loaded from a view (it is an MVC project).

I added a listener to render the PDF, using eopdf.convert(), after the map has loaded, as recommended here (http://www.essentialobjects.com/forum/postsm30801_Google-Maps.aspx), but the process times out, and I suspect that call is never occurring. I have tried putting in Console debug lines, but none of them are coming through.

I have created a simple repro app. Is there a way I can get it to you to investigate?

Thanks,

Jason

Thanks for your response. I am pretty sure that I am using the latest version: 5.0.23.2. I downloaded it yesterday. Is there a more recent version that is stable that I should be using?

Thanks.

Hi Jason,

We have looked into your test project. We couldn't reproduce the problem but I did not see you set HtmlToPdf.Options.BaseUrl. You must set HtmlToPdf.Options.BaseUrl correctly when calling ConvertHtml because otherwise it wouldn't be able to correctly resolve the relative paths.

You can also try the new MVCToPDF feature in the new build. MVCToPDF will automatically set BaseUrl for you. You can find more information about MVCToPDF here:

http://www.essentialobjects.com/doc/4/web/mvc.aspx

Thanks!