Resource busy or locked

Wolfteam

Hi, im not sure why this bug happens, but sometimes (heavy load?), i get this error .
And the only way to fix it is to kill the blocked process (chrome.exe) using the Resource Monitor

Error rendering report: A critical error occurred while trying to execute the render command: An error occurred while trying to start daemonized process: An error has occurred when trying to initialize jsreport (2). EBUSY: resource busy or locked, open 'C:\Program Files (x86)\Apps (PROD)\Admin\jsreport\temp\jsreport\compile\jsreport-2.5.0-BymsTkv0E\chrome\chrome.exe' (1). caused by error (2) -> meta = {"code":"EBUSY"}, stack = Error:     at instance.init.then.catch ([eval]:66283:29)    at tryCatcher (jsreportRuntime.js:158306:23)    at Promise._settlePromiseFromHandler (jsreportRuntime.js:157998:31)    at Promise._settlePromise (jsreportRuntime.js:158055:18)    at Promise._settlePromise0 (jsreportRuntime.js:158100:10)    at Promise._settlePromises (jsreportRuntime.js:158176:18)    at _drainQueueStep (jsreportRuntime.js:39442:12)    at _drainQueue (jsreportRuntime.js:39435:9)    at Async._drainQueues (jsreportRuntime.js:39451:5)    at Immediate.Async.drainQueues (jsreportRuntime.js:39321:14)    at runCallback (timers.js:794:20)    at tryOnImmediate (timers.js:752:5)    at processImmediate [as _immediateCallback] (timers.js:729:5)caused by error (1) -> meta = {"errno":-4082,"code":"EBUSY","syscall":"open","path":"C:\\Program Files (x86)\\Apps (PROD)\\Admin\\jsreport\\temp\\jsreport\\compile\\jsreport-2.5.0-BymsTkv0E\\chrome\\chrome.exe"}, stack = Error:  (1). caused by error (1) -> meta = {"code":"EBUSY"}, stack = Error:     at exports.NsSocket.socket.dataOnce ([eval]:66671:25)    at exports.NsSocket.listener ([eval]:13402:10)    at exports.NsSocket.EventEmitter.emit ([eval]:13490:22)    at exports.NsSocket._onData ([eval]:94250:8)    at Lazy.<anonymous> ([eval]:74361:13)    at Lazy.<anonymous> ([eval]:74343:19)    at emitTwo (events.js:126:13)    at Lazy.emit (events.js:214:7)    at Lazy.<anonymous> ([eval]:74344:22)    at emitOne (events.js:116:13)    at Lazy.emit (events.js:211:7)    at yieldTo ([eval]:74451:18)    at Function.<anonymous> ([eval]:74489:27)    at Lazy.<anonymous> ([eval]:74457:21)    at emitOne (events.js:116:13)    at Lazy.emit (events.js:211:7)

Im using it locally, with the following config:

bool isPortSpecified = int.TryParse(ConfigurationManager.AppSettings["JsReportPort"], out int httport);
            if (!isPortSpecified)
            {
                throw new NullReferenceException("The JsReportPort must be specified in the config file");
            }

            bool isTimeOutSpecified = int.TryParse(ConfigurationManager.AppSettings["JsReportTimeOut"], out int timeOut);
            if (!isTimeOutSpecified)
            {
                throw new NullReferenceException("The JsReportTimeOut must be specified in the config file");
            }

            return new LocalReporting()
                .UseBinary(JsReportBinary.GetBinary())
                .Configure(cfg =>
                {
                    cfg.BaseUrlAsWorkingDirectory().AllowedLocalFilesAccess();
                    cfg.TempDirectory = Path.Combine(HostingEnvironment.MapPath("~"), "jsreport", "temp");
                    cfg.Chrome = new ChromeConfiguration
                    {
                        Timeout = timeOut * 1000
                    };
                    cfg.HttpPort = httport;
                    return cfg;
                })
                .AsUtility()
                .Create();

jan_blaha

We have done some improvements in this are in jsreport 2.6.0.
We will soon ship it to the .net nugets. Likely at the end of the week.
I will post here an update.

Wolfteam

Hiho, im not sure if this helps, but in the render.js file https://github.com/jsreport/jsreport-cli/blob/master/lib/commands/render.js#L211 ?
the retry delay is too low, shouldn't be bigger ?

jan_blaha

We pre-released package jsreport.Binary@2.6.2-beta.
Among other fixes, it covers also this mentioned problem. It now uses a mutex lock to prevent parallel starts.
Please update and let us know if you have further problems.

Wolfteam

Hiho, with the 2.6.2-beta i get the following exception:

2019-11-22 09:40:28,927 [8] ERROR ReportLogger An unexpected error occurred while trying to generate the invoice report.
jsreport.Local.JsReportBinaryException: Error rendering report: Error: read ECONNRESET at TCP.onStreamRead (internal/stream_base_commons.js:111:27)
at jsreport.Local.Internal.LocalUtilityReportingService.<RenderAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Backend.Util.ReportUtil.<GenerateInvoiceReportAsync>d__6.MoveNext() in C:\Projects\Backend\ReportUtil.cs:line 111

Aside from that, im getting weird crashes, that makes the app go down :C
Exception thrown: 'System.UnauthorizedAccessException' in mscorlib.dll

jan_blaha

I apologize for the constant problems with the jsreport binary and .net wrapper.
I've now released jsreport.Binary@2.6.2-beta and jsreport.Local@2.2.0 and I hope the problems are fixed there.

The problem introduced in the 2.6.2-beta was that we were using lockfile to prevent concurrency problems when initializing jsreport binary.
Unfortunately, the lockfile was written to the working directory and in case of a web app caused the app pool to recycle.
This resulted in a loop and unexpected crashes.
We write the lockfile now to the specified temp so it should be ok.
The jsreport.Local also includes some fixes for concurrent starts and better errors.

Please let us know if you get to test the released nugets.

Wolfteam

I did some tests this week, and it seems to be working fine /,,, /

jan_blaha

Great, thank you. We soon release the final version with the fixes.