OCR Engine

asked on June 7, 2019

Hello,

We've built a Laserfiche interface that adds/moves/deletes and OCR's documents in Laserfiche. We are running into an issue when we call the OCR engine the windows service our integration is running in spins to 100% CPU usage and never comes back down. Once this starts happening at a client location, it never stops, ever time the OCR engine is called the process spins up. We've had this happen on 10.2, 10.3, and 10.4. We have at least one client currently experiencing the issue, and can replicate it on demand.

using (OcrEngine ocrEngine = OcrEngine.LoadEngine())
{
ocrEngine.AutoOrient = true;
ocrEngine.Decolumnize = true;
ocrEngine.OptimizationMode = OcrOptimizationMode.Accuracy;
ocrEngine.Run(doc);
}

Does anyone know why this might happen and how to prevent it?

0 0

replied on June 7, 2019

Are you closing down the OCR engine when the process is complete?

OCREngine instances can be reused, so they don't close down on their own.

0 0

View 1 previous reply

replied on June 7, 2019

Jason

Shouldn't the using block close and release the OCR Engine?

using (OcrEngine ocrEngine = OcrEngine.LoadEngine())

0 0

replied on June 7, 2019 • Show version history

Using statements will handle garbage collection activities like calling Dispose on a document object, but I don't think they would execute a close method.

The object reference would be disposed of, but the engine may still exist. Kind of like exiting a remote desktop session without logging out.

Something similar happens when you create a repository session in a using statement; the reference will be gone, but the connection remains active if you don't actually close it.

(We had this problem with a vendor making repository connections but never disconnecting so the connections remained active until the server timed them out for inactivity)

According to Microsoft using statements only relate to IDisposable, which is about releasing memory/resources, not shutting down connections and such.

"Using" is basically just a try-catch-finally and .Dispose() rolled into one block.

0 0

replied on June 10, 2019

We applied this change, unfortunately it had no effect, same issue is still occuring.

0 0

Question

Question

Replies

Sign in to reply to this post.