|
|
Rank: Member
Groups: Member
Joined: 6/19/2012
Posts: 11
|
We have built you pdf library in our CMS system to implement the feature to convert html pages to pdf. We use a asp.net page which uses the ConvertHtml function for this.
It seems that every time the BaseURL property is different (different domains) a new engine is started (rundll32). Why is this?
Even if there are already several engines running which have nothing to do, still a new engine is started. This takes a lot of resources for nothing, could you not just reuse initialized engines which are idle because most engines are killed after about 20 minutes of being idle instead of being reused.
We are using the latest build 4.0.18.2.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Hi,
We do reuse the engine regardless of BaseUrl. So what you are seeing might be a bug. Please try to create a test project demonstrating the problem and send the test project to us. We will investigate further once we have that.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/19/2012
Posts: 11
|
I just did a test with the following code:
Code: Visual Basic.NET
<%@ Page Language="VB" ContentType="text/html" ResponseEncoding="utf-8" EnableViewState="False"%>
<%@ Import Namespace="EO.Pdf" %>
<script runat="server">
Sub Page_Load()
Dim objPdfDocument As New PdfDocument
Dim objResult As HtmlToPdfResult
Dim objRandom As New Random
objPdfDocument.Document.Info.Author = "Test"
objPdfDocument.Document.Info.Producer = "Test"
objPdfDocument.Document.Info.Creator = "Test"
objPdfDocument.Document.Info.CreationDate = DateTime.Now
objPdfDocument.Document.Info.Title = "Test"
objPdfDocument.Document.Info.Subject = "Test"
objPdfDocument.Document.Security.Permissions = (PdfDocumentPermissions.CopyingContents Or PdfDocumentPermissions.Printing Or PdfDocumentPermissions.Printing)
HtmlToPdf.Options.BaseUrl = "http://www.test.local"
HtmlToPdf.Options.PageSize = PdfPageSizes.A4
HtmlToPdf.Options.AutoFitX = HtmlToPdfAutoFitMode.ShrinkToFit
HtmlToPdf.Options.AutoFitY = HtmlToPdfAutoFitMode.None
HtmlToPdf.Options.NoLink = True
HtmlToPdf.Options.NoCache = True
HtmlToPdf.Options.PreserveHighResImages = True
HtmlToPdf.Options.OutputArea = New System.Drawing.RectangleF(0.4F, 0.4F, 7.5F, 10.9F)
objResult = HtmlToPdf.ConvertHtml("<html><body>Test</body></html>", objPdfDocument)
Response.Clear()
Response.ContentType = "application/pdf"
Response.AddHeader("content-disposition", "attachment;filename=""Test.pdf""")
objPdfDocument.Save(Response.OutputStream)
Response.Flush()
Response.End()
End Sub
</script>
<html>
<head runat="server">
<title>test</title>
</head>
<body>
</body>
</html>
It seems that it is not the BaseURL (the same every time) yet multiple engines are created. When you call this page the first time an engine is created. After the page is finished and you call this page again a second engine is created (first one is idle). After this the second created engine keeps being used. But is we go to a different website (other domain / host header, but same application pool and home directory) and call the same page a third engine is created. After this is finished and you call this page again and a fourth engine is created. So now we have four running engines but only one engine is needed because there are no concurrent calls. We use the latest version and have the DLL in the global assembly cache. I hope this is enough information.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Thanks for the additional information. This would be an issue. We will look into it and let you know.
|
|
Rank: Member
Groups: Member
Joined: 6/19/2012
Posts: 11
|
eo_support wrote:Thanks for the additional information. This would be an issue. We will look into it and let you know.
Any updates on this because on our production server sometimes there are more than 10 engines running which is starting to get a problem.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Hi,
We have not been able to reproduce this issue. The only situation you will get a lot of engines is when you have that many concurrent conversions. For example, if conversion A is still in progress and you wish to start another conversion B, then a new engine will be created. This behavior is by design.
We did find a few other issues related to the engines, we will post a new build before the end of today (.22). You can check that build once it's posted and see if it works better for you.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/19/2012
Posts: 11
|
Maybe it is because we are using the DLL in our module (with own global.asax and web.config) which is included in all our website as an application directory (IIS7). Maybe in this situation the context may be different in every websites so you do not correctly determine if already an engine is started, but all the websites with module run in the same application pool and therefore use one w3wp worker process.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Hi, That makes perfect sense. The engines are managed by your app domain. If you have multiple app domains, then each app domain will maintain their own engines. It has nothing to do with whether these domains are within the same process or not. To workaround this problem, install EOPDFSP service on your production machine: http://www.essentialobjects.com/doc/4/htmltopdf/eopdfsp.aspxOnce you have the service running, all conversion will be done through the service, which runs a single app domain to manage all engines. Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/19/2012
Posts: 11
|
We installed the service we get the following error event:
Failed to create named pipe. error code:998
The service is running but as far we can see the service is not used and we still get multiple engines.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Hi,
In that case you probably want to change your code to use a single app domain only. We do not know why you have 998 error and in order to investigate it we will need to debug it on your machine. So if you can give us remote desktop access we will try to run debug code on your machine to see if we can find out the root cause.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 6/19/2012
Posts: 11
|
eo_support wrote:Hi,
So if you can give us remote desktop access we will try to run debug code on your machine to see if we can find out the root cause.
Thanks! Unfortunately this is not possible for security reasons. We will experiment a bit further and see what we can find ourselves.
|
|