I dont want to compare apple with orange, this was already done, for example, in:
http://blog.shinetech.com/2011/06/10/nodejs-from-the-enterprise-java-perspective/
http://adamgent.com/post/10440924094/does-java-have-an-answer-to-node-js
Actually, I do not have a concurrency problem with JBoss AS 7, but if I had on, what should I do?
Should I:
SOLUTION I:
horizontal/vertical scale
use HTTPD in front of JBoss AS
use @Asynchrounous or Messaging Systems (such as AKKA) for ALL tasks
...
SOLUTION II:
Can anyone provide practical experiences where JBoss AS 7 failed to scale? I have never had such experiences for myself.
For example, imagine a web application with 10.000.000 concurrent request *on a single machine* (with a single jboss-as-instance or a single node.js-instance).
What would be the result?
Would node.js works normally while JBoss AS 7 crash?
In general, Java EE is primarily targetted at high-scale application and most of the design decisions comply to that, from persistence over session and cache replication to view layers.
While Node.js may be good for certain tasks, Java EE 6 is (IMO) good if you want to use it for whole stack.
There's more comming regarding scalability, like JSR-352. So Java EE is yet to improve.
Regarding your question - "while JBoss AS 7 crash" - it doesn't generally crash. Usually it's faulty or poorly written application what crashes. Node.js gives certain API. Java EE gives a multitude of APIs, which sometimes are misused or conceptually misunderstood, which results in problems like OutOfMemoryException. With a properly designed application, there should be no problem with horizontal scaling.
There are few proven examples of node.js supporting a large and popular application as of yet. Like any new technology of this type, it will get tested and if it scales will garner support. Nobody can truly answer your question from a technical standpoint.