Speaking only for myself as ever:<p>Handling out of memory errors is a hard problem. At the point when you can't allocate more memory you are busted in most languages. For example in C a slightly deeper function call depth can cause the stack to expand at any point. If that point coincides with you running out of memory then you are busted. No program can keep running with a broken stack.<p>If V8 were capable of recovering from out-of-memory errors then you would still have to go through all of node and all the native libraries that it uses and check that they can handle any allocation failing.<p>And if V8 handled out-of-memory errors with exceptions then you have two choices. Either make the exceptions uncatchable, in which case the JS program running in the server has no way to recover and is probably in an inconsistent state. Or make the exceptions catchable, in which case there is no guarantee that any memory will ever be freed up and you are back to square one.<p>I think it's possible to make V8 more resistant to out of memory situations. I don't think it's possible to make it bulletproof, and I don't think there are many server apps that have this property. Do people run Java servers in such a way that they are often getting out of memory exceptions, recovering, and then continuing to serve? I don't think so.<p>In practice the way most servers work is that you give them plenty of memory and you write your server app in such a way that it does not use unlimited memory.<p>If there are non-out-of-memory errors that V8 is failing to recover from then these are bugs and should be reported. I can't think of any examples off-hand.<p>As far as the other comments go they seem to assume that you will want to use a V8 context per connection. Node uses one V8 context for all connections, so the comments don't apply. Context creation has been speeded up a lot since the article was written, but this is only for the browser. Node doesn't need it.
Sysoev brings up a couple good points that affect Node.js .<p>1) The fact memory allocation might crash the process is a serious problem. Is this still the case?<p>2) The fact that garbage collection is still stop-the-world may be a problem for server availability. Are we able to call the generational collector from node, or no?<p>Things that don't involve node:<p>The ability to create multiple objects in different contexts. Sysoev is thinking of the "scripting" model, like PHP, which is not how Node does things. Node just runs one process to handle thousands of requests, not thousands of processes or threads. There is no need.
While an interesting article in its own right, it has nothing to do with node.js, except that this happens to be a criticism of the way V8 works, which node.js is built on. However, they may not be using things in the same way he is, or there could be mitigating circumstances which make it possible for node.js to pull this off. (I don't know anything about node.js internals, I just know this article isn't about it, as the title indicates.)<p>Edit: This was written when the title was "The author of Nginx on node.js and why V8 is not suitable for web servers". It's since been changed.
At Microsoft, I watched (from afar) the incredibly painful multi-year process of making a complex language runtime intended for one environment (.NET for IIS) satisfy the requirements of a very different environment (SQL Server). When fundamental design assumptions like "memory allocation failures can kill the process" have to change, it's a big deal.<p>Seems like process isolation a la fastcgi is the practical way to go, unless the V8 team itself wants V8 to be embeddable in a "reliable" way (meaning, it recovers from its own errors without corrupting the process it's embedded in).
Node.js is often used because it is cool, new and easier for front-end developers to develop a functioning backend.<p>For more traditional uses that want something less hackish, erlang for example, crashes only a single thread not the entire vm. Functional programming languages in general like haskell and erlang are interesting for backend core services.
The state of todays base of node (v8) has nothing to do with the concept/paradigm its trying to put forward -- that is <i>event driven web apps</i>. Hence, one must not discard node as a bad solution only because v8 is not optimal in all situations.<p>Everything is always a work in progress.
These only sound like problems if you need to keep it single process. If you break out the javascript interpreter via fastcgi workers just like people do with php on nginx it becomes mostly moot points right? At that point its limited to 500 req/sec/core, but frankly these days that means 4000 req/s, which, hell, I'll take it.<p>Granted thats assuming you can actually run a fastcgi/v8 setup, I've never looked. I wonder how hard a mod_v8 for apache prefork would be.
As I'm sure others will point out, this article has less to do with node.js as it does with embedding v8 in Nginx. Although since node.js runs in v8, I suppose you could interpret it that way.
IIRC, on Linux at least the memory allocation thing is moot. If your process runs out of memory, it dies anyway. You can't catch "malloc says no" because malloc never says no. It either says yes or blows your process's brains out.
A lot of the points raised are an issue only for long running processes. Akshell (<a href="http://www.akshell.com" rel="nofollow">http://www.akshell.com</a>), for example, has synchronous I/O libraries and uses an Apache MPM like model, so for us the limits are less of a concern.
I keep seeing these replies on how well Google Translate performed. I didn't realize while reading that it was machine-translated, but my immediate thought was "this person is not a native English speaker or needs much work his attempt at Yoda-speak does."
it's a great write up and the context issue seems interesting, however it's from Feb 2010 according to the last paragraph and a lot has changed in V8 since
A thought: why not have node developers fork V8, and modify that to make it ready for server deployment? Has the coreteam and/or Dahl thought about this?
in russian : Почему Google V8 пока не подходит для встраивания в серверы
in english : Why is Google V8 is not suitable for integration into servers.<p>There is a word "integration" that the author of the post forgot to put in.
Hmmm... I read this title as 'The author of Nginx on why (Nginx) V8 is not suitable for web servers' and I'm thinking ... huh?<p>Does someone want to change the title to be clearer?
Right title for this 2 years old article is "Why V8 is not suitable for nginx".<p>He has his own set of requirements which by no means applies to _all_ webservers.
It sounds like more of the concern is that V8 is/was buggy & had some situations where performance would be compromised. I don't think it's a slam saying it could never be used.