Welcome Guest Search | Active Topics | Sign In | Register

Essential Objects Product Support Forum » All Products » Support » What happens in EO.Internal.air.a that could cause a quick timeout exception?

What happens in EO.Internal.air.a that could cause a quick timeout exception? Options
Previous Topic · Next Topic
ecachim
Posted: Wednesday, May 3, 2017 12:12:15 PM
Rank: Newbie
Groups: Member

Joined: 9/4/2013
Posts: 2
Question: what happens in EO.Internal.air.a? What could be causing this error?

Our application crashes on and off (more on than off) with the following event in the event viewer

Code:

Event detail code: 0

Application information:
    Application domain: /LM/W3SVC/1/ROOT/test/server/107-1-131377790095613572
    Trust level: Full
    Application Virtual Path: /test/server/107
    Application Path: D:\XXXXXXX\test-server-107\
    Machine name: WIN-I8SQO02DSQN

Process information:
    Process ID: 6948
    Process name: w3wp.exe
    Account name: IIS APPPOOL\XXXXXXX-test-server-107

Exception information:
    Exception type: Exception
    Exception message: The operation has timed out.
   at EO.Internal.air.a(ala A_0)
   at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
   at EO.Pdf.HtmlToPdf.ConvertUrl(String url, Stream stream, HtmlToPdfOptions options)
   at XXXXXXX.Web.Pdf.PdfGenerator.Convert(String url, PageOrientation pageOrientation) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.Impl.Pdf\PdfGenerator.cs:line 122
   at XXXXXXX.Web.Pdf.PdfGenerator.ConvertFromHtmlToPdf(String url, PageOrientation pageOrientation) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.Impl.Pdf\PdfGenerator.cs:line 61
   at XXXXXXX.Web.Impl.PdfUtil.GeneratePdf(Uri uri, DocumentTypeEnum documentType, HttpContext context) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.Impl\PdfUtil.cs:line 89
   at XXXXXXX.Web.IIS.HttpHandlers.PdfHttpHandler.ProcessRequest(HttpContext context) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.IIS\HttpHandlers\PdfHttpHandler.cs:line 121
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)



Request information:
    Request URL: https://test.XXXXXXX.com:443/test/server/107/pdfGenerator?typeDescription=XXXXXXX-viewmodel/License&persistenceId=13664&externalLang=en&internalLang=en&emergencyNumber=+32 70 245 245&standard=CLP&ranges=true&amount=100l&documentType=Msds&uiBuild=170427-1442
    Request path: /test/server/107/pdfGenerator
    User host address: NNN.NNN.NNN.NNN
    User: janeca
    Is authenticated: True
    Authentication Type: 
    Thread account name: IIS APPPOOL\XXXXXXX-test-server-107

Thread information:
    Thread ID: 37
    Thread account name: IIS APPPOOL\XXXXXXX-test-server-107
    Is impersonating: False
    Stack trace:    at EO.Internal.air.a(ala A_0)
   at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
   at EO.Pdf.HtmlToPdf.ConvertUrl(String url, Stream stream, HtmlToPdfOptions options)
   at XXXXXXX.Web.Pdf.PdfGenerator.Convert(String url, PageOrientation pageOrientation) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.Impl.Pdf\PdfGenerator.cs:line 122
   at XXXXXXX.Web.Pdf.PdfGenerator.ConvertFromHtmlToPdf(String url, PageOrientation pageOrientation) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.Impl.Pdf\PdfGenerator.cs:line 61
   at XXXXXXX.Web.Impl.PdfUtil.GeneratePdf(Uri uri, DocumentTypeEnum documentType, HttpContext context) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.Impl\PdfUtil.cs:line 89
   at XXXXXXX.Web.IIS.HttpHandlers.PdfHttpHandler.ProcessRequest(HttpContext context) in c:\TeamCity1\work\a3c0ec0cb8972499\src\XXXXXXX.Web.IIS\HttpHandlers\PdfHttpHandler.cs:line 121
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


Custom event details:


Neither the version of EoPDF (16.0.91, using the Classic renderer), nor the backend code, changed since the previous, working version, nor where any Windows updates or other changes made to the machine the application runs on.
Since the last working version, the JavaScript in the page that should be rendered changed a bit (a/o, an update of dojo 1.11.3 --> 1.12.2). None of these changes seem relevant to this issue, but this is impossible to debug with EoPDF.

Rendering takes often 20s or more, and we had trouble before towards the end of the render.
This error however occurs almost immediately (within 3s of the receipt of the HTTP call).
It seems like something goes wrong very early in the initialisation of the rendering process, that is the result of a race condition (hence the works / doesn't work randomness). Given the quick error, we do not believe this is truly a timeout, unless it is a timeout of 1s or so for a system resource.

Can you tell us what happens in EO.Internal.air.a that could cause this error?
That might help us track down the problem.
Back to top
 
eo_support
Posted: Wednesday, May 3, 2017 2:03:06 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,229
Hi,

This usually indicate a crash inside the browser engine. You can try to comment out the contents in your HTML block by block and see if you can locate anything that triggers the crash. Because the classic engine is based on a rather old WebKit based browser engine, it may not be able to handle something in your page and crashed. In that case you would need to avoid the triggering part in your HTML.

Alternatively you can also try the current version and see if it resolves the issue for you. The current version uses a rather up to date Chromium browser engine (your version can use Chromium engine as well but the engine is not as updated). Due to the complete open source nature of the Chromium browser engine, it allows us to trace into the source code to find out exactly what's causing the crash. Additionally, even if you can not reliably reproduce it, you can still take advantage of the automatic crash report of the new version:

https://www.essentialobjects.com/doc/common/crash_report.aspx

This allows us to catch additional crash information on our server in order to pinpoint exactly what happened when it crashes, and may eventually lead to a solution to the problem.

Thanks!
Back to top
 
ecachim
Posted: Thursday, May 4, 2017 3:42:31 AM
Rank: Newbie
Groups: Member

Joined: 9/4/2013
Posts: 2
Thanks for the response.

Quote:
the classic engine is based on a rather old WebKit based browser engine

Quote:
your version can use Chromium engine as well but the engine is not as updated


1) I don't understand
Quote:
your version can use Chromium engine as well but the engine is not as updated

Can you elaborate?

2) Can you tell me which Chromium version is comparable with the classic engine?
We could start out with trying the page with that Chromium version outside of EOPdf, in an attempt for a quick fix.

According to our logs, the User Agent reports as

Code:

Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/534+ (KHTML, like Gecko) Chrome/25.0.168.0


Would Chrome 25.0.168 be a close match? Is there a close Chromium version?
Back to top
 
eo_support
Posted: Thursday, May 4, 2017 1:38:19 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,229
Hi,

The classic engine is based on WebKit 534, which was released around year 2010. WebKit is an open source layout engine originated from Apple's Safari browser engine but later has been adopted by Google as the starting point of Google's Chromium project, which is the open source portion of the Google Chrome browser. Chromium V6 to V12 is based on various builds of WebKit 534. However our classic engine has no direct relationship with Chromium. It's just both EO.Pdf classic engine and early version of Chromium uses WebKit.

The "Chrome/25" you see in Agent string does not mean it's actually Chrome 25, it was necessary for us to add this part because many web pages have code that detects browser type/versions. Even though EO.Pdf is based on WebKit, it is neither Apple Safari nor Google Chrome. Nevertheless, we can not have an agent string that is unrecognizable by those pages who attempts to detect browser. So we added Chrome into the agent string to instruct the page to treat us as Chrome. It does not mean it's actually Chrome, and the version number 25 here does not really matter much because it is not Chrome to begin with.

Over the years Google has forked WebKit and developed it into its own Blink layout engine. Integrating this with many other parts that forms the core of Google's Chrome browser (such as resource loader, cache manager, navigation manager, Google's own V8 JavaScript engine etc) and it forms the Chromium browser engine, which is much more than the original layout engine.

EO.Pdf 2016 (your version) introduces the new engine that is based on Chromium browser engine V49. From a technical point of view, Chromium is Chrome (chrome contains some parts that can not be open sourced). So technically you can think the new engine in EO.Pdf 2016 is Chrome V49. The agent string for the new engine should match those of Chrome's agent string exactly since they are "almost" the same thing (we do modify Chromium's source code, so there are still differences). To help our users to transit to the new engine, we kept the old engine (the classic engine you use) in 2016.

The current version EO.Pdf 2017 updated from Chromium 49 to Chromium V54. It has also removed the classic engine. So it is completely Chromium powered now.

Hope this gives you enough information. Please feel free to let us know if you still have any questions.

Thanks!
Back to top
 


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.