It would be hard to preempt the thread since node is single threaded, but you could wrap the event sources and measure how long a tick took to run. Then if it took longer than a threshold you could log a warning or throw an error. Sadly there is no node api for easy wrapping of the event sources yet, but I did it manually once for a module.
https://github.com/CrabDude/trycatch/blob/master/lib/hook.js On Wed, Jun 6, 2012 at 9:42 AM, José F. Romaniello <[email protected]>wrote: > this might sound very stupid,... but wouldn't be useful to have a > parameter or something to set the max milliseconds a tick can take? > > node myapp.js --tick-timeout 60000 > > this means if you have a while(true), or something than takes more than a > minute fail!, raise an exception in the application so you can log it on > the process "uncaughException" event. and something like "forever" will > restart the process. > Maybe there is no way to implement this right now, or maybe there is > something like this already... > > cheers, > > 2012/6/6 Matt <[email protected]> > >> This doesn't change the fact that external monitoring is still going to >> be better. >> >> On Wed, Jun 6, 2012 at 1:27 AM, Jeff Willden <[email protected]>wrote: >> >>> Some readers are not getting the point. When running node in a >>> production environment, it is assumed that the app has no blatant >>> infinite loops. Yes, that would block the event loop and prevent >>> anything from running, but if you've done that, you should take Intro >>> to Node 101, or maybe the remedial class... >>> >>> In a production environment, we're concerned about long running events >>> that might be blocking the event loop. If your code is doing database >>> calls, then it's yielding to the event loop. No problem there. But >>> then if you run a bunch of processing on that using synchronous code, >>> and that processing takes longer than whatever threshold you give in >>> the code I posted, then it will tell you. We're not concerned as much >>> about overall request time, because during the time it's processing >>> the request, it's probably yielding. For newbies, yielding means that >>> you perform some action and pass it a callback, and when that action >>> is done, it calls the callback. Users see this all over in node code. >>> That doesn't necessarily mean it yields though... >>> >>> Case scenario: we had a bunch of db calls to load data that would be >>> processed (sorted, organized, transformed, etc) and converted to json >>> and then fed to the client. That db calls yield each time a db call is >>> made. No problem. The processing was all linear programming. Problem: >>> for large data sets it was taking over our threshold. When you have >>> more concurrent requests than the number of instances of node (we're >>> using cluster) then every instance is busy and your server goes >>> unresponsive. BAD news. We had to change some calls to accept a >>> callback, and then it would call the callback inside a >>> process.nextTick(). That made the code async, and the problem >>> disappeared. We could ramp up with hundreds of users and the users >>> with only a little data got served fast, the users with lots of data >>> not quite as fast, but at least they weren't blocking other users. >>> >>> People often misunderstand how to build server-side apps with Node. >>> With async coding in node, you can easily outmatch performance for >>> lots of other environments. With synchronous code in node, you can >>> easily have a dead server. Node is great, but it's oh-so-easy to shoot >>> yourself in the foot. Gotta be really careful about excessive runs of >>> synchronous code. >>> >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en >>> >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
