Graphics Mill v 5.0 (the trial x86 version available for download) fails our load test.
Here's what we do in our load test:
1. Create a memory stream from the jpg file
2. Load the memory stream into a
Aurigma.GraphicsMill.Codecs.JpegReader3. Use the JpegReader from step #2 to create a
Aurigma.GraphicsMill.Codecs.JpegFrame. The frame is used to get the height, width, and bits/pixel.
4. Load the memory stream into a
Aurigma.GraphicsMill.Codecs.LosslessJpegTransform.
5. Add a watermark using the LosslessJpegTransform's WritePatched.
6. Add a thin frame by calling WritePatched around the border.
We run 35 threads. After a total of about 100,000 iterations (total of all threads) of the above steps in about 5 hours, Jpgs can no longer be processed.
We get an error in step 4 above. The message is "
Some unexpected error occured. If you see this message, please contact..."
Here's the stack trace:
at Aurigma.GraphicsMill.Codecs.LosslessJpegTransform._Open(Stream stream)
at Aurigma.GraphicsMill.Codecs.LosslessJpegTransform.Open(Stream stream)
at Aurigma.GraphicsMill.Codecs.LosslessJpegTransform..ctor(Stream stream)Also, from step step 6 above, we get "
Unable to create temporary file 'C:\WINDOWS\TEMP\ICM5124_BE8A.TMP'." sprinkled in among the errors. The file name is different for every temp file error, of course.
Here's the stack trace for these errors:
at Aurigma.GraphicsMill.Thread.FireStoppedEvent(Object object, ErrorEventArgs args)
at Aurigma.GraphicsMill.Thread.TimerEventProcessor()
at Aurigma.GraphicsMill.Thread.ChangeActivityStatus(ActivityStatus status)
at Aurigma.GraphicsMill.Thread.EntryPoint()
at Aurigma.GraphicsMill.Thread.Start()
at Aurigma.GraphicsMill.Codecs.FormatReader._FrameLoadBitmap(Frame frame)
at Aurigma.GraphicsMill.Codecs.Frame._GetBitmap(Bitmap bitmap)
at Aurigma.GraphicsMill.Codecs.Frame.GetBitmap(Bitmap bitmap)
at Aurigma.GraphicsMill.Bitmap.Load(Stream stream)
at Aurigma.GraphicsMill.Bitmap._Load(Stream stream)
at Aurigma.GraphicsMill.Bitmap..ctor(Stream stream)The bitmap we are trying to create is a crop of one of the borders of the jpg. The idea is to draw a line on the bitmap and then call WritePatched to put the crop back into the jpeg with a "frame" added.
We know load is the problem because the problems occur on jpgs that processed fine earlier in the load test.
I should also note that we are using Windows 2003 Server with IIS 6.0. The CPU is an AMD Opteron 285, dual 2.61Ghz. There is 1.25 GB RAM. So, not your typical beefy server.
The w3wp.exe that hosts the host load test steadily gets a bigger and bigger Working Set (memory usage). It gets up to about 660MB before the errors start occuring. After the errors, the Working Set stays at around 260MB for the remainder of the test during all the errors. I'm not sure if we could interpret this as a memory leak or not.
I do know that the LosslessJpegTransform had a memory leak in v4.5. I know that because we ran Debug Diagnostic Tool on a memory dump. And it reported likely memory leaks from this stack:
Aurigma_GraphicsMill+12b50a
Aurigma_GraphicsMill+e3073
Aurigma_GraphicsMill+e2b04
Aurigma_GraphicsMill+1d7681
Aurigma_GraphicsMill+1d768f
Aurigma.GraphicsMill.Codecs.NonSeekableStreamProxy.Seek(Int64, System.IO.SeekOrigin)
Aurigma.GraphicsMill.Codecs.NonSeekableStreamProxy.Seek(Int64, System.IO.SeekOrigin)
Aurigma.GraphicsMill.Codecs.FormatReader._Open(System.IO.Stream)
Aurigma.GraphicsMill.Codecs.FormatReader._Open(System.IO.Stream)
Aurigma.GraphicsMill.Codecs.FormatReader.Open(System.IO.Stream)
Aurigma.GraphicsMill.Codecs.LosslessJpegTransform._Open(System.IO.Stream)
Aurigma.GraphicsMill.Codecs.LosslessJpegTransform._Open(System.IO.Stream) The processor is pegged at 100% during the entire test, even when the errors occur.
Hope this is enough information.
Edited by user Thursday, May 22, 2008 1:25:14 PM(UTC)
| Reason: Not specified