Logo
My Account |  Site Map | Contact Us  
Welcome Guest Search | Active Topics | Sign In | Register

Handling issues with WebView objects when using HtmlToPdf.Convert* Options
autree
Posted: Tuesday, October 2, 2018 4:58:53 PM
Rank: Newbie
Groups: Member

Joined: 10/2/2018
Posts: 5
I'm using a recent version of the product: 18.1.31.0

I have a service which converts pages from another server into pdfs on a somewhat regular basis using the HtmlToPdf.ConvertUrl method. A few times, this service has started failing, with exception messsage:

This WebView either has already been destroyed or is being destroyed.

After that, every subsequent call to the method is failing with the same error, until the process is restarted. Unfortunately, this seems to be random and rare and I haven't been able to catch it in a controlled environment. I don't even have a stack track right now, our log is throwing it away.

Ideally, I'd like to have a way to get the service back to normal without having to restart. Might I need to rewrite this to use something other than HtmlToPdf.ConvertUrl so I can get at the underlying WebView/Engine objects?
eo_support
Posted: Wednesday, October 3, 2018 8:32:00 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 20,678
Hi,

Unfortunately while the underlying WebView object is accessible to you but there is no way for you to recover from this scenario. We will have to reproduce it and fix it on our end. So if there is any way you can help us reproducing it it would be of great help in resolving this issue.

The reason that you won't be able to recover from this scenario is because internally EO.Pdf maintans a pool of WebView objects and it has a rather complex logic to reuse/recycling them. For example, one part of this logic is to dispose a WebView if it has been idle for a while, another part of this logic is to recreate the WebView when it has died unexpectedly. Obviously this part is not working property in your case. In order to troubleshoot, we will need a reproducing case. See here for more information on how to send test project to us:

https://www.essentialobjects.com/forum/test_project.aspx

Thanks!

autree
Posted: Wednesday, October 3, 2018 9:03:01 AM
Rank: Newbie
Groups: Member

Joined: 10/2/2018
Posts: 5
Thanks for the reply. In previous threads on the topic of this error, I believe support recommended handling an event on the WebView to get more detailed information about why it was closed. I wonder if this might help me reproduce the issue. How do I get at the underlying WebView object?
eo_support
Posted: Wednesday, October 3, 2018 9:36:25 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 20,678
Hi,

See here for sample code on how to access the underlying WebView object:

https://www.essentialobjects.com/doc/eo.pdf.htmltopdfsession.runwebviewcallback_overload_1.aspx

However we handle exactly the same event (WebView.Closed) event internally. So the problem might be that event not being fired properly in your case.

Thanks!
autree
Posted: Wednesday, October 3, 2018 2:02:46 PM
Rank: Newbie
Groups: Member

Joined: 10/2/2018
Posts: 5
It seems like to do what we're talking about, I would have to replace calls to HtmlToPdf.ConvertUrl with something like

using (var session = HtmlToPdfSession.Create())
{
session.LoadUrl(url);
session.RenderAsPDF(doc);
}

Is this correct?
eo_support
Posted: Wednesday, October 3, 2018 2:08:35 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 20,678
Yes. You will need to use HtmlToPdfSession object in order to gain access to the underlying WebView object.
autree
Posted: Tuesday, October 9, 2018 10:06:05 AM
Rank: Newbie
Groups: Member

Joined: 10/2/2018
Posts: 5
So, I've replaced our call to HtmlToPdf.ConvertUrl(string url, PdfDocument doc, HtmlToPdfOptions options) with the below method, in order to try and capture any extra information when the problem occurs:

using (var session = HtmlToPdfSession.Create(options))
{
session.RunWebViewCallback((view, args) =>
{
view.LoadFailed -= LoadFailedCallback;
view.LoadFailed += LoadFailedCallback;
view.Closed -= ViewClosedCallback;
view.Closed += ViewClosedCallback;
view.RenderUnresponsive -= RenderUnresponsiveCallback;
view.RenderUnresponsive += RenderUnresponsiveCallback;
return null;
}, null);
session.LoadUrl(url);
session.RenderAsPDF(doc);
}

One thing I've noticed is, when I use the above code in a console application, the WebView.Closed callback is executed as soon as the application stops running, with reason WebViewCloseReason.Normal. In my actual service, which runs on IIS, nothing has so far been logged from this callback, even when IIS is reset or application pool recycled. Another event, WebView.LoadCompleted, is firing as I would expect. Is this normal and, if not, could it be related to my problem? Also, are there any other events I could be hooking into to get more information?
eo_support
Posted: Tuesday, October 9, 2018 10:50:48 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 20,678
Hi,

These events are far from certain to be fired, especially when running inside environments like IIS when process is recycled regularly. When the process is killed, everything is terminated right way --- there is no in process clean up in this case. So it's completely normal that such events may not fire.

I believe the most effective approach for you to track down this kind of problem is reproduce it first. Once you can reproduce it, you can share the test project/steps with us and we will try to reproduce it and then debug into it here, hopefully that will help us to get to the bottom of it.

Thanks!
autree
Posted: Tuesday, October 9, 2018 11:43:02 AM
Rank: Newbie
Groups: Member

Joined: 10/2/2018
Posts: 5
I'd like to be able to reproduce the issue, but I think that will be infeasible without more information (it's only happened 3 times, among many thousands of conversions). I have no evidence that the error is due to a bad response from the url being converted, and I suspect it only occurs after my service has been active for a while. Do you have any suggestions for an approach to reproducing the problem?
eo_support
Posted: Tuesday, October 9, 2018 11:59:45 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 20,678
I am not sure what else we can suggest. We do know that the path you are following right now most likely will lead to a dead end because we handle this event as well. The only thing we can do at this point is to pay extra attention on our end for this issue and hopefully we can catch it somewhere else either from another customer or in our own environment.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.