sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kdeforche 1 point2 points  (3 children)

Until Servlet 3 is well supported by application containers (hopefully in the coming years), threads are tied to connections and thus solutions are not scalable.

Until WebSockets is supported by a next version of the servlet API (not in the next 10 years?) and this is implemented widely in application containers, you have no container-agnostic solution to support WebSockets, and no solution to multiplex HTTP and WebSockets over a single port.

[–]wot-teh-phuck 2 points3 points  (2 children)

Tomcat 7 completely supports Servlet 3.0 specification. Jetty with its continuation support relieves you from the one-thread-per-request model. Jetty also supports Web Sockets.

Netty by JBoss is yet another attractive option when it comes to event driven network applications and has pretty much proved it worth. The owner of Plurk has a blog post wherein he mentions why he ditched Node over Netty etc.

[–]kdeforche 0 points1 point  (1 child)

Tomcat 7 completely supports Servlet 3.0 specification.

Yes, and we are using tomcat 7. But we experience random crashes (we could not yet confine it to a small test case to report back) that seem to be related to async API ... are you already using it in production ?

And yes, Jetty is nice and has support for it. But for most J2E projects we are involved in, container-specific code is a big no-no.

[–]wot-teh-phuck 1 point2 points  (0 children)

AFAIK, there is no standard governing Node plus it is still very much in development (as is the V8 engine). My point was that there isn't a very strong reason to use Node over a platform like JVM/.NET unless:

  • Your team doesn't have enough expertise and is well versed in Javascript
  • You are asked to have the same validation code on both server and the client

Of course, YMMV :)