Open joe-spanning opened 10 years ago
+1
I too just started having the same exact problem. I'm also processing large amounts of data, using recursive promises, to elegantly handle both rate limiting and calls for subsequent pages where I don't know where the end is.
It hums along great for several hours (was watching htop
the entire time to monitor for potential memory leaks), but eventually terminates with the above error.
to elegantly handle both rate limiting and calls for subsequent pages where I don't know where the end is.
On this note I should note a separate relevant, IE has flawed handling of its setImmediate function. In some cases setTimeout loops and DOM modifications can result in setImmediate callbacks never being called. http://codeforhire.com/2013/09/21/setimmediate-and-messagechannel-broken-on-internet-explorer-10/
@dantman: that's a valid concern that should be taken into consideration, but just in the interest of debugging this: at least for my case, it's entirely in a server-side environment with no front-end interaction.
@joe-spanning: Thanks for logging this issue, you saved me some debugging time. I am using the exact same pattern. My code looks like:
function onScriptInput() {
self.promptForInput()
.then(lineReader.readLine)
.then(self.onEchoInput)
.then(self.compileAndExecuteScript)
.then(self.printResult)
.catch(function(err) { console.error(chalk.bold.red(err)); })
.done(onScriptInput);
}
It seems I can work around the problem by inserting a delay of 1ms:
function onScriptInput() {
self.promptForInput()
.then(lineReader.readLine)
.then(self.onEchoInput)
.then(self.compileAndExecuteScript)
.then(self.printResult)
.catch(function(err) { console.error(chalk.bold.red(err)); })
.delay(1)
.done(onScriptInput);
}
+1
+1, this is a bad design that produces heavy effects when application load increases, late in development flow :-(
I am using Q 1.0.1 and Node.js 0.10.24
I have a application that uses Q to recursively process large amounts of data using the following pattern:
If there is a large amount of data to process in this way, I eventually get the error:
This error is not caught by my
fail
handler function, so I cannot recover from it. It comes across as an uncaught exception in Node. However, this is not the point of me creating the ticket.The error states that
setImmediate
should be used instead ofprocess.nextTick
. Looking at the source of q.js lines 158 - 177:It prefers process.nextTick to setImmediate.
If would be nice if this code was changed to use
setImmediate
, or if I could configure Q to prefersetImmediate
overprocess.nextTick
via an environment variable.