Mass Conversion Failures - Essential Objects, Inc. Support Forum

Welcome Guest

Search | Active Topics | Sign In | Register

Essential Objects Product Support Forum » All Products » Support » Mass Conversion Failures

Mass Conversion Failures

Options

Previous Topic · Next Topic

CWoods

Posted: Wednesday, July 16, 2014 1:51:42 PM

Rank: Advanced Member
Groups: Member

Joined: 7/14/2014
Posts: 40

I'm working on running a large scale test of EO.Pdf to evaluate its potential use in our systems. This test is primarily to get a sense of performance, backlogs, and load demand that the component would be subjected to as part of its normal daily usage in our systems. Secondary purpose of the test is assessing how many documents fail to convert (and why).

The test application is running 4 "worker threads" that are draining an internal queue and calling EO.Pdf for conversion and one thread that is responsible for populating the queue based on the input file contents (which specifies the files and time when it should be submitted). It is running on 4 CPU Windows 2008R2 x64 VM w/16GB of memory using .NET 4.5.1 and EO.Pdf version 5.0.85.2 (EO.Total v109) - with no license key (we're still doing trial). Based on my other thread (http://www.essentialobjects.com/forum/postst8426_EOPDF-Out-of-Memory-and-Zombie-Rundll32exe.aspx) I'm running each call to EO.Pdf in a separate child AppDomain which is setup before the call and destroyed after the call (I actually meant to use one of the more refined approaches but left the wrong approach enabled in the test application when I ran it).

My first full test set is 4768 HTML documents - this represents a heavier than average volume day's worth of documents. What I experienced during the first run of the test was that after successfully converting 1924 HTML documents (about 2 hours and 13 minutes into the test), it suddenly started failing to convert filings and failed on every single test document after that after 2-3 secs into each conversion.

000157093113000020|2014-07-15T19:42:03.3705|0|0.00:00:00.0000|0|0.00:00:02.1143|0.00:00:02.1143|False|Thread 4: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Value cannot be null.
Parameter name: hdc ---> System.ArgumentNullException: Value cannot be null.
Parameter name: hdc
at System.Drawing.Graphics.FromHdc(IntPtr hdc)
at EO.Pdf.Internal.d2.a(BinaryReader A_0, Size A_1, IntPtr A_2, Int32 A_3)
at EO.Pdf.Internal.d2..ctor(BinaryReader A_0, Size A_1, Int32 A_2)
at EO.Pdf.Internal.hb..ctor(BinaryReader A_0)
at EO.Pdf.Internal.be.a(Byte[] A_0, Single A_1, Single A_2, Single A_3, Single& A_4, Double A_5, Double A_6)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44
000110465913063818|2014-07-15T19:42:02.3705|0|0.00:00:00.0000|0|0.00:00:03.1143|0.00:00:03.1143|False|Thread 5: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Arithmetic operation resulted in an overflow. ---> System.OverflowException: Arithmetic operation resulted in an overflow.
at EO.Pdf.Internal.en.a(IntPtr A_0)
at EO.Pdf.Internal.en.a(j4 A_0)
at EO.Pdf.Internal.en.b(j4 A_0)
at EO.Pdf.Drawing.PdfFont..ctor(j4 A_0, Single A_1)
at EO.Pdf.Internal.fo.b(kb A_0)
at EO.Pdf.Internal.fo.a(j8[] A_0)
at EO.Pdf.Internal.fo..ctor(lu A_0, Boolean A_1, Int32 A_2, kv A_3, Int32 A_4, Single A_5, Rectangle A_6, PdfPage A_7, d2 A_8, Int32 A_9, Graphics A_10, Dictionary`2 A_11)
at EO.Pdf.Internal.lu.a(PdfPage A_0, Boolean A_1, Int32 A_2, Rectangle A_3, kv A_4, hb A_5, Int32& A_6, Graphics A_7)
at EO.Pdf.Internal.lu.a(Int32 A_0, HtmlToPdfResult A_1, Int32& A_2)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44
000095015613000066|2014-07-15T19:42:02.3705|0|0.00:00:00.0000|0|0.00:00:03.1993|0.00:00:03.1993|False|Thread 6: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Value cannot be null.
Parameter name: hdc ---> System.ArgumentNullException: Value cannot be null.
Parameter name: hdc
at System.Drawing.Graphics.FromHdc(IntPtr hdc)
at EO.Pdf.Internal.d2.a(BinaryReader A_0, Size A_1, IntPtr A_2, Int32 A_3)
at EO.Pdf.Internal.d2..ctor(BinaryReader A_0, Size A_1, Int32 A_2)
at EO.Pdf.Internal.hb..ctor(BinaryReader A_0)
at EO.Pdf.Internal.be.a(Byte[] A_0, Single A_1, Single A_2, Single A_3, Single& A_4, Double A_5, Double A_6)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44
000153261813000006|2014-07-15T19:42:03.3705|0|0.00:00:00.0000|0|0.00:00:02.2237|0.00:00:02.2237|False|Thread 3: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Value cannot be null.
Parameter name: hdc ---> System.ArgumentNullException: Value cannot be null.
Parameter name: hdc
at System.Drawing.Graphics.FromHdc(IntPtr hdc)
at EO.Pdf.Internal.d2.a(BinaryReader A_0, Size A_1, IntPtr A_2, Int32 A_3)
at EO.Pdf.Internal.d2..ctor(BinaryReader A_0, Size A_1, Int32 A_2)
at EO.Pdf.Internal.hb..ctor(BinaryReader A_0)
at EO.Pdf.Internal.be.a(Byte[] A_0, Single A_1, Single A_2, Single A_3, Single& A_4, Double A_5, Double A_6)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44

I thought maybe I was pushing the application too hard and was not giving .NET (or Windows OS) enough time to do GC and other housekeeping (due to seeing "hdc" in the exception). I had compressed out all idle gaps in the simulation to expedite the run - if all workers are idle then the queuing thread immediately jumps to the next time slot of files and starts injecting them into the queue. Being 2+ hours into the test I thought this unlikely (as I would have expected it to die much sooner if I was really preventing GC) however I modified the test application to allow idle gaps of 10 seconds or less between batches to remain and then re-ran the the test. (10 second is a long time on a modern multi-CPU server...)

The second run of the test (same document set) starting failing again after 1924 HTML documents (about 4 hours and 8 minutes into the test - compared to the first run you can see how much time those idle gaps really added up). The first document to report failure is different but it's at the same point/files in the test as the last run.

000110465913063818|2014-07-16T04:50:47.7424|0|0.00:00:00.0000|0|0.00:00:02.8819|0.00:00:02.8819|False|Thread 5: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Arithmetic operation resulted in an overflow. ---> System.OverflowException: Arithmetic operation resulted in an overflow.
at EO.Pdf.Internal.en.a(IntPtr A_0)
at EO.Pdf.Internal.en.a(j4 A_0)
at EO.Pdf.Internal.en.b(j4 A_0)
at EO.Pdf.Drawing.PdfFont..ctor(j4 A_0, Single A_1)
at EO.Pdf.Internal.fo.b(kb A_0)
at EO.Pdf.Internal.fo.a(j8[] A_0)
at EO.Pdf.Internal.fo..ctor(lu A_0, Boolean A_1, Int32 A_2, kv A_3, Int32 A_4, Single A_5, Rectangle A_6, PdfPage A_7, d2 A_8, Int32 A_9, Graphics A_10, Dictionary`2 A_11)
at EO.Pdf.Internal.lu.a(PdfPage A_0, Boolean A_1, Int32 A_2, Rectangle A_3, kv A_4, hb A_5, Int32& A_6, Graphics A_7)
at EO.Pdf.Internal.lu.a(Int32 A_0, HtmlToPdfResult A_1, Int32& A_2)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44
000095015613000066|2014-07-16T04:50:47.7424|0|0.00:00:00.0000|0|0.00:00:02.9727|0.00:00:02.9727|False|Thread 3: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Value cannot be null.
Parameter name: hdc ---> System.ArgumentNullException: Value cannot be null.
Parameter name: hdc
at System.Drawing.Graphics.FromHdc(IntPtr hdc)
at EO.Pdf.Internal.d2.a(BinaryReader A_0, Size A_1, IntPtr A_2, Int32 A_3)
at EO.Pdf.Internal.d2..ctor(BinaryReader A_0, Size A_1, Int32 A_2)
at EO.Pdf.Internal.hb..ctor(BinaryReader A_0)
at EO.Pdf.Internal.be.a(Byte[] A_0, Single A_1, Single A_2, Single A_3, Single& A_4, Double A_5, Double A_6)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44
000157093113000020|2014-07-16T04:50:48.7424|0|0.00:00:00.0000|0|0.00:00:02.0830|0.00:00:02.0830|False|Thread 4: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Value cannot be null.
Parameter name: hdc ---> System.ArgumentNullException: Value cannot be null.
Parameter name: hdc
at System.Drawing.Graphics.FromHdc(IntPtr hdc)
at EO.Pdf.Internal.d2.a(BinaryReader A_0, Size A_1, IntPtr A_2, Int32 A_3)
at EO.Pdf.Internal.d2..ctor(BinaryReader A_0, Size A_1, Int32 A_2)
at EO.Pdf.Internal.hb..ctor(BinaryReader A_0)
at EO.Pdf.Internal.be.a(Byte[] A_0, Single A_1, Single A_2, Single A_3, Single& A_4, Double A_5, Double A_6)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44
000153261813000006|2014-07-16T04:50:48.7424|0|0.00:00:00.0000|0|0.00:00:02.2442|0.00:00:02.2442|False|Thread 6: Exception caught: EO.Pdf.HtmlToPdfException: Convertion failed. Value cannot be null.
Parameter name: hdc ---> System.ArgumentNullException: Value cannot be null.
Parameter name: hdc
at System.Drawing.Graphics.FromHdc(IntPtr hdc)
at EO.Pdf.Internal.d2.a(BinaryReader A_0, Size A_1, IntPtr A_2, Int32 A_3)
at EO.Pdf.Internal.d2..ctor(BinaryReader A_0, Size A_1, Int32 A_2)
at EO.Pdf.Internal.hb..ctor(BinaryReader A_0)
at EO.Pdf.Internal.be.a(Byte[] A_0, Single A_1, Single A_2, Single A_3, Single& A_4, Double A_5, Double A_6)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdfSession.RenderAsPDF(PdfDocument doc)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, PdfDocument doc, HtmlToPdfOptions options)
at EO.Pdf.HtmlToPdf.ConvertUrl(String url, String pdfFileName, HtmlToPdfOptions options)
at FeedReplay.Worker.PdfConverter.Process(Request req) in c:\Projects\Source\ThrowAways\FeedReplay\Worker.cs:line 44

I pulled 136 entries out of the test's input file that led up to these files, included them, and a few files after to create a mini-test to see if I could figure out if there was something in particular about these files that would cause a crash. The test however ran to completion w/out any conversion failures. The files of this mini-test are submitted in the same order and spacing as in the full test. I reran the test and noted at one point that the memory of the test application itself (not the Rundll32.exe child processes) shot up pretty high (from 350MB to about 2.3GB) for about 2 minutes during the middle of the test and then returned to normal ranges (back to 350MB) well before the test was over. Since the test application is a 64-bit application, the server has 16GB of memory, and this is essentially the only thing running on the server while I'm concerned/puzzled by the spike I don't see it as being a smoking gun for the sudden conversion failure situation that I see during the full tests. I ran the mini-test again and captured a number of performance counters using perfmon (which I can provide). None of the runs failed to convert any of the filings however.

eo_support

Posted: Wednesday, July 16, 2014 4:05:22 PM

Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,071

Hi,

Both exceptions indicate a problem with GDI object. The first stack trace is caused by CreateCompatibleDC returning NULL. The second stack trace is caused by failure to create a font. This can happen when either the system or the process is reaching GDI handle/memory limits. This limit does not have much to do with your system memory and can be configured through registry.

The first thing you want to check is if there is a GDI handle leak. In order to do so you can check the "GDI Object" in task manager and see if it grows steadily for your .NET process (rundll32 shouldn't matter since they get killed and recycled anyway). If it grows steadily and never comes down, then there must be a GDI handle leak somewhere. In that case please try to isolate the problem into a test app and send the test app to us. You should not need the whole test file set in order to reproduce this problem.

The huge memory spike might has to do with a specific file in your test set. Other than the obvious (for example, huge images, overly complex HTML, etc), two things that can easily trigger huge memory spike are CSS shadow and run away JavaScript code. So you can try to focus those two things to see if you can find out what triggered the spike.

Thanks!

CWoods

Posted: Wednesday, July 16, 2014 5:46:26 PM

Rank: Advanced Member
Groups: Member

Joined: 7/14/2014
Posts: 40

Quote:

The first thing you want to check is if there is a GDI handle leak. In order to do so you can check the "GDI Object" in task manager and see if it grows steadily for your .NET process (rundll32 shouldn't matter since they get killed and recycled anyway). If it grows steadily and never comes down, then there must be a GDI handle leak somewhere.

So yes I would say it's a GDI leak. I re-ran the "mini-test" that I ran before (~136 files) and watched GDI Objects with SysInternal's Process Explorer:

- 400 GDI objects just around 3 minutes into the test
- Fluctuated from upper 300 to just over 400 for a few minutes
- 500 GDI objects just around 8 minutes into the test
- 600 GDI objects around 9 minutes into the test
- 700 GDI objects around 10 minutes into the test
- ~750+ GDI objects when the test completed at around 10 minutes 43 seconds

Sorry I can't be more precise as I was having to watch these due to the fact that GDI Objects isn't exposed as a performance counter and I don't have a better recording tool. My test application is a bit more involved than the simple one that I provided in the other thread (http://www.essentialobjects.com/forum/postst8426_EOPDF-Out-of-Memory-and-Zombie-Rundll32exe.aspx) due to the extra worker threads/queue/etc... however it basically boils down to that example - except for using different files per worker thread instead of them all trying to convert the same file and that each request uses it's own child AppDomain. I'm trying the mini-test set out with a simple single threaded "serial" conversion scenario to see if the GDI handle count. I'll try to send something later tonight as I have to step away for a while.

Quote:

The huge memory spike might has to do with a specific file in your test set. Other than the obvious (for example, huge images, overly complex HTML, etc), two things that can easily trigger huge memory spike are CSS shadow and run away JavaScript code. So you can try to focus those two things to see if you can find out what triggered the spike.

Not sure what you are referring to with regards to "CSS shadow" but there's no JavaScript code running in any of these HTML files. It could however very well be a very complex HTML document. We do have some documents that are mostly tables with many thousands of cells. I'll try to correlate the memory balloon with particular file(s) being processed and narrow it down to a repeatable test of a couple files. If the filings don't look overly complex/massive then I'll send them to you for further investigation.

CWoods

Posted: Thursday, July 17, 2014 12:23:53 AM

Rank: Advanced Member
Groups: Member

Joined: 7/14/2014
Posts: 40

Update: It would appear that the GDI leak is related to the use of the child AppDomain (which we added from the other thread to protect us from "zombies").

For all of the following tests I used a simple single threaded conversion loop over a very small set of HTML files:
Test #1: Called for the conversion directly w/ no child AppDomain. GDI got as high as 30.
Test #2: Each conversion called from a new child AppDomain instance which was torn down after the request. GDI climbed to 101 by the end of the test.
Test #3: Created a single child AppDomain and each conversion called reusing one MarshalByRefObject derived class. GDI got as high as 30.
Test #4: Created a single child AppDomain and each conversion called using a new instance of the MarshalByRefObject derived class. GDI got as high as 30.
Test #5: Each conversion called from a new child AppDomain instance which I did not call Unload() on (except the last) - I wanted to let the RunDLL32 instances idle timeout and then see what the GDI was at the end. GDI got as high as 101 after the last conversion. After 20 minutes the RunDLL32 instances started timing out but the GDI never went down...

So I'm thinking (just a guess on my part) that the cleanup code that's enabled for the child AppDomain Unload event may be causing/allowing the leak. It's possible that whatever the leak is isn't directly related to the child AppDomain but rather a leak that's been hidden as if you don't run within a child domain (or if you use just the one) then you probably never "see" the leak as it's cleaned up by the application terminating. Hope this helps!

[Then again maybe I've done something wrong with the child AppDomain/MarshalByRefObject... I've not used them before but doesn't look like there's much that I could do differently with it.]

Here's the code from Test #2:

Code: C#

Copy

//http://www.superstarcoders.com/blogs/posts/executing-code-in-a-separate-application-domain-using-c-sharp.aspx
        public sealed class Isolated<T> : IDisposable where T : MarshalByRefObject
        {
            private AppDomain _domain;
            private T _value;

            public Isolated()
            {
                _domain = AppDomain.CreateDomain("Isolated:" + Guid.NewGuid(),
                                                 null, AppDomain.CurrentDomain.SetupInformation);
                Type type = typeof(T);
                _value = (T)_domain.CreateInstanceAndUnwrap(type.Assembly.FullName, type.FullName);
            }

            public T Value { get { return _value; } }

            public void Dispose()
            {
                if (_domain != null)
                {
                    AppDomain.Unload(_domain);
                    _domain = null;
                }
            }
        }

        class PdfConv : MarshalByRefObject
        {
            public void Convert(string filepath)
            {
                EO.Pdf.HtmlToPdf.Options.AutoFitX = EO.Pdf.HtmlToPdfAutoFitMode.ShrinkToFit;
                EO.Pdf.HtmlToPdf.Options.GeneratePageImages = false;
                EO.Pdf.HtmlToPdf.Options.NoCache = true;
                EO.Pdf.HtmlToPdf.Options.OutputArea = new RectangleF(0.25f, 0.25f, 8.0f, 10.5f);
                EO.Pdf.HtmlToPdf.Options.PageSize = EO.Pdf.PdfPageSizes.Letter;

                Console.WriteLine("Processing file: {0}", filepath);
                EO.Pdf.HtmlToPdf.ConvertUrl(filepath, filepath + ".pdf");
            }
        }

        static void Main(string[] args)
        {
            // Child AppDomain per request - Big GDI Leak (101 for 18 HTML files)
            foreach (string filepath in Directory.EnumerateFiles(args[0], "*.html").ToList())
            {
                using (Isolated<PdfConv> isolated = new Isolated<PdfConv>())
                {
                    isolated.Value.Convert(filepath);
                }
            }
        }

CWoods

Posted: Monday, July 21, 2014 2:55:14 PM

Rank: Advanced Member
Groups: Member

Joined: 7/14/2014
Posts: 40

Tested with 110 build (EO.Pdf 5.0.86.2). GDI object count still climbs according to Process Explorer when AppDomains are unloaded.

eo_support

Posted: Thursday, July 24, 2014 10:34:23 AM

Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,071

Hi,

We have posted a new build that should fix the GDI resource leak issue. The DLL version is 5.0.87.2. The GDI resource leak is the only fix in this build, so if you no longer uses child domains, then it may no longer matter to you. You can see your private message for the download location of the new build.

Thanks!

CWoods

Posted: Thursday, July 24, 2014 10:38:10 AM

Rank: Advanced Member
Groups: Member

Joined: 7/14/2014
Posts: 40

Thanks. If there is no longer a reason to still use the child AppDomain then I guess it doesn't matter too much any more per se in this particular case however we might also use it in IIS application and it would there if/when IIS unloads the application. I will pull down the new build and post my results later today.

Thanks!

CWoods

Posted: Thursday, July 24, 2014 12:15:02 PM

Rank: Advanced Member
Groups: Member

Joined: 7/14/2014
Posts: 40

Confirmed. No GDI leaks reported when run test in which each request is performed in a separate child AppDomain instance.

Thanks!

eo_support

Posted: Thursday, July 24, 2014 12:25:59 PM

Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,071

You are very welcome and thank you very much for confirming the fix! Please feel free to let us know if there is anything else.

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.

Message