6 ms·

Impressive. It's basically a kinda-sorta-rewrite of Node.js APIs on the JVM. Looking through the docs, the main difference I see is that this is opting for a c

by Animus7 14y ago

Impressive. It's basically a kinda-sorta-rewrite of Node.js APIs on the JVM. Looking through the docs, the main difference I see is that this is opting for a comparatively heavy-core approach which contrasts with Node's ruthless minimalism + third-party modules. For example: -file system access is convoluted with HTTP handling: req.response.sendFile() -pieces of web framework functionality by default, but no full solution (RouteMatcher) -integrated WebSockets with a novel but unconventional accept/reject API -heavyweight SockJS integration It will be interesting how all of his plays out. And I'm definitely interested in hearing evidence for claims such as > a run-time with real concurrency and unrivalled performance

stephen 14y ago
> -file system access is convoluted with HTTP handling: req.response.sendFile() I haven't looked in to it, but just guessing this is probably so that it can do 0-copy sending of files (e.g. doesn't have to buffer/stream the contents through the JVM).
- purplefox 14y ago
  That's right. If you use the sendFile() method and you're on an OS that supports it, then the kernel will do the copying directly from file to socket for you. You can also serve files in the more conventional "node.js-style" way (i.e. pump the buffers manually from file to socket) if you like. It's just slower than getting the kernel to do the work for you.
  - dap 14y ago
    But you have to dedicate a thread to sendFile() (by nature).
    - jbooth 14y ago
      Not really, typically you'd have one thread handling all sendFiles through a single selector over the destination sockets. As a matter of fact, it's actually really painful to do sendFile in Java from a single thread, because when the channel isn't ready for sending, rather than returning EAGAIN and letting you busy-loop or wait/retry or whatever, it throws an exception. So you have to use a selector to do sendfile, and in that case, why not use multiple tasks with the same selector?
    - dap 14y ago
      (Response to jbooth, but for some reason I can't reply to that directly.) The whole point of sendfile is to make one system call to send all the data in one stream to another, which in general may block. If you're polling and sending only small chunks at a time (whatever you can write without blocking), is it really that much of an advantage over read/write on the same poll? (If you're not doing that, then you have to block, and you have to dedicate a thread to it.)
      - jbooth 14y ago
        If the socket you're writing to has been set to nonblocking, then sendfile exhibits the behavior I described, sending EAGAIN sometimes (check man sendfile). This means typically you want to put a selector in front of it and poll the selector, then send to any sockets that are writable, loop back and poll again. It's still an advantage over read/write because you're getting the 0-copy behavior.
bascule 14y ago
"real concurrency" is a silly term, but I assume he means threads and therefore a multicore concurrency model vis-a-vis thread-level parallelism, allowing a single VM to utilize all cores in the system. This is opposed to Node, which must run at least one VM for each CPU in order to utilize all of the cores in a system, unless your only use of threads is ThreadPoolExecutor-style pools, then you can use the horrible hack that is threads-a-gogo
- purplefox 14y ago
  Yes, I meant threads ;) E.g. A web server using node.js on a 32 core server. You would have to manually manage 32 instances of node, and use a load balancer or the cluster module in order to route requests to the instances. With vert.x you just start one instance and from the command line you tell it how many instances to start. It then scales over your cores, no glue code or cluster module to write. (There's an example of this on the front page of the website).
  - mbq 14y ago
    Having VM per core may be quite beneficial -- you get more fault tolerance, immunity to GC glitches and one tier less when scaling over several machines. And there are nice tools to manage multiple processes.

by Animus7 14y ago

stephen 14y ago

> -file system access is convoluted with HTTP handling: req.response.sendFile() I haven't looked in to it, but just guessing this is probably so that it can do 0-copy sending of files (e.g. doesn't have to buffer/stream the contents through the JVM).

purplefox 14y ago
That's right. If you use the sendFile() method and you're on an OS that supports it, then the kernel will do the copying directly from file to socket for you. You can also serve files in the more conventional "node.js-style" way (i.e. pump the buffers manually from file to socket) if you like. It's just slower than getting the kernel to do the work for you.
- dap 14y ago
  But you have to dedicate a thread to sendFile() (by nature).
  - jbooth 14y ago
    Not really, typically you'd have one thread handling all sendFiles through a single selector over the destination sockets. As a matter of fact, it's actually really painful to do sendFile in Java from a single thread, because when the channel isn't ready for sending, rather than returning EAGAIN and letting you busy-loop or wait/retry or whatever, it throws an exception. So you have to use a selector to do sendfile, and in that case, why not use multiple tasks with the same selector?
  - dap 14y ago
    (Response to jbooth, but for some reason I can't reply to that directly.) The whole point of sendfile is to make one system call to send all the data in one stream to another, which in general may block. If you're polling and sending only small chunks at a time (whatever you can write without blocking), is it really that much of an advantage over read/write on the same poll? (If you're not doing that, then you have to block, and you have to dedicate a thread to it.)
    - jbooth 14y ago
      If the socket you're writing to has been set to nonblocking, then sendfile exhibits the behavior I described, sending EAGAIN sometimes (check man sendfile). This means typically you want to put a selector in front of it and poll the selector, then send to any sockets that are writable, loop back and poll again. It's still an advantage over read/write because you're getting the 0-copy behavior.

bascule 14y ago

"real concurrency" is a silly term, but I assume he means threads and therefore a multicore concurrency model vis-a-vis thread-level parallelism, allowing a single VM to utilize all cores in the system. This is opposed to Node, which must run at least one VM for each CPU in order to utilize all of the cores in a system, unless your only use of threads is ThreadPoolExecutor-style pools, then you can use the horrible hack that is threads-a-gogo

purplefox 14y ago
Yes, I meant threads ;) E.g. A web server using node.js on a 32 core server. You would have to manually manage 32 instances of node, and use a load balancer or the cluster module in order to route requests to the instances. With vert.x you just start one instance and from the command line you tell it how many instances to start. It then scales over your cores, no glue code or cluster module to write. (There's an example of this on the front page of the website).
- mbq 14y ago
  Having VM per core may be quite beneficial -- you get more fault tolerance, immunity to GC glitches and one tier less when scaling over several machines. And there are nice tools to manage multiple processes.