Error when launching multiple instances of jsreport (v1.x) with --keepAlive flag on cmd line

peterlitvak

In our workflow we have the case when multiple instance of jsreport are launched on a command line to render the reports at the same time with the --keepAlive flag. The expected behavior is that all of the command line executions will succeed. The actual behavior is that a few of those command line executions fail with the following error:

at onCriticalError (/usr/local/var/jsreport/node_modules/jsreport-cli/lib/commands/render.js:302:25)
     at /usr/local/var/jsreport/node_modules/jsreport-cli/lib/commands/render.js:257:13
     at tryCatcher (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/util.js:16:23)
     at Promise._settlePromiseFromHandler (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/promise.js:510:31)
     at Promise._settlePromise (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/promise.js:567:18)
     at Promise._settlePromise0 (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/promise.js:612:10)
     at Promise._settlePromises (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/promise.js:687:18)
     at Async._drainQueue (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/async.js:133:16)
     at Async._drainQueues (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/async.js:143:10)
     at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/var/jsreport/node_modules/jsreport-cli/node_modules/bluebird/js/release/async.js:17:14)
     at runCallback (timers.js:696:18)
     at tryOnImmediate (timers.js:667:5)
     at processImmediate (timers.js:649:5) {"originalError":{}}
 (Original) Error: An error occurred while trying to start daemonized process: An error has occurred when trying to initialize jsreport.. seems like there is already a server running in port: 5488
     at exports.NsSocket.<anonymous> (/usr/local/var/jsreport/node_modules/jsreport-cli/lib/keepAliveProcess.js:128:13)
     at exports.NsSocket.listener (/usr/local/var/jsreport/node_modules/eventemitter2/lib/eventemitter2.js:251:10)
     at exports.NsSocket.EventEmitter.emit (/usr/local/var/jsreport/node_modules/eventemitter2/lib/eventemitter2.js:339:22)
     at exports.NsSocket._onData (/usr/local/var/jsreport/node_modules/nssocket/lib/nssocket.js:454:8)
     at Lazy.<anonymous> (/usr/local/var/jsreport/node_modules/lazy/lazy.js:91:13)
     at Lazy.<anonymous> (/usr/local/var/jsreport/node_modules/lazy/lazy.js:73:19)
     at Lazy.emit (events.js:182:13)
     at Lazy.<anonymous> (/usr/local/var/jsreport/node_modules/lazy/lazy.js:74:22)
     at Lazy.emit (events.js:182:13)
     at yieldTo (/usr/local/var/jsreport/node_modules/lazy/lazy.js:181:18)
     at Function.<anonymous> (/usr/local/var/jsreport/node_modules/lazy/lazy.js:219:27)
     at Lazy.<anonymous> (/usr/local/var/jsreport/node_modules/lazy/lazy.js:187:21)
     at Lazy.emit (events.js:182:13)
     at Socket.<anonymous> (/usr/local/var/jsreport/node_modules/lazy/lazy.js:50:22)
     at Socket.emit (events.js:182:13)
     at emitReadable_ (_stream_readable.js:531:12)
     at process._tickCallback (internal/process/next_tick.js:63:19) {}

bjrmatos

hi!, we see this behaviour only when multiple jsreport render --keepAlive call are being done and the background process is not initialized (a single jsreport render --keepAlive was not done before), so the cause for the error in this scenario is that all calls try to initialize jsreport on specific port (5488) and only one wins and the other fail, basically we fail to support the scenario in which --keepAlive tries to initialize the daemon process concurrently. i just want to add that we support concurrent renders perfectly when the background process was already created, the issue is only when the background process is not created and multiple calls try to create it.

we've created an issue to track and implemented the support the concurrent start of --keepAlive. i just want to mention that when the fix is ready it will be part of jsreport v2, since you are using jsreport v1 you will need to migrate to v2 to be able to see it in action.

the quick workaround for your workflow will be to retry the command after some time is passed if some error was throw, this will correctly handle the case when only one call pass and the next calls fail, those call should wait a bit and then the call should be retried.

peterlitvak

Ok, it is a bit disappointing, though, to learn this will not be back-ported to 1.x since we were not going to migrate to 2.x anytime soon.

bjrmatos

we will see, at first i can't tell you if it is easy to back-port it to 1.x, we usually don't do that, but let's see.. if the change is easy to fix and back-port it would not take so much effort it can be done, but no promise

peterlitvak

much appreciated!