Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vert.x – JVM Polyglot Alternative to Node.js

infoq.com

Post reply on HN
Print view View original

51–60 of 83 posts

Re: Vert.x – JVM Polyglot Alternative to Node.js

#51

Post by Locke1689 »

kyleburton wrote: post #31
Locke1689 wrote: post #21

Earlier quoted context omitted.

What are you talking about? libevent invented everything Node.js uses and Python's Twisted had and has everything Node.js could dream of. Node.js is just a reinvention of old technologies in Javascript. Edit: Removed flame about Javascript because I don't want to have this debate again.

I am talking about the cultures surrounding these languages and frameworks. Node's community rejects blocking libraries. Java's does not. I've used the non-blocking frameworks in Perl (POE and my own), C (select, and some of the poll variants), Ruby (event machine) and they are fine if you can avoid blocking libraries -- in these communities it is generally acceptable to write blocking libraries. I don't see it as a…

You need to start backing up your claims with actual data. What networking libraries are blocking in Node.js that are not blocking in Twisted? Moreover, what can't you do with a Twisted Deferred that you can do in Node.js?

There are two main things that block in computing:

* I/O

* CPU

You better believe that Node blocks on CPU, so what I/O does Node not block on that Twisted does?

Re: Vert.x – JVM Polyglot Alternative to Node.js

#52

Post by d503 »

tensor wrote: post #35
Uchikoma wrote: post #28

Earlier quoted context omitted.

There is no async MySDQL JDBC driver. If you encapsulate it in an async layer, you need to keep a thread for the connection.

Maybe I am missing something, but how can you possibly have an async SQL driver without threads like this? This sounds like a case of your Node.js database driver hiding the exact same behaviour described here within C code.

PostgresSQL's libpq supports nonblocking asynchronous operation, and node-postgres takes advantage of that.

http://www.postgresql.org/docs/9.1/static/libpq-async.html

https://github.com/brianc/node-postgres/blob/master/src/bind...

(notice the Connect method on line 325 of binding.cc)

At some level a client-server database driver isn't all that different from any other network client; you send a request over a socket and wait for a result. There's no reason you have to block while waiting.

Moreover some databases (like Postgres) let you receive asynchronous notifications signaled by transactions on other connections; that's how trigger-based replication systems like Bucardo do their thing.

http://www.postgresql.org/docs/9.1/static/sql-notify.html

Re: Vert.x – JVM Polyglot Alternative to Node.js

#53

Post by kodablah »

tensor wrote: post #35
Uchikoma wrote: post #28

Earlier quoted context omitted.

There is no async MySDQL JDBC driver. If you encapsulate it in an async layer, you need to keep a thread for the connection.

Maybe I am missing something, but how can you possibly have an async SQL driver without threads like this? This sounds like a case of your Node.js database driver hiding the exact same behaviour described here within C code.

Because it would be based on asynchronous socket responses. So you wouldn't iterate like you currently do w/ a ResultSet but rather have a simple "RowHandler" or sorts. However you still run into the trouble you do w/ node if you decide to do a lot of blocking work in there instead of just sending the row to some ExecutorService thread to get worked on.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#54

Post by purplefox »

tensor wrote: post #35
Uchikoma wrote: post #28

Earlier quoted context omitted.

There is no async MySDQL JDBC driver. If you encapsulate it in an async layer, you need to keep a thread for the connection.

Maybe I am missing something, but how can you possibly have an async SQL driver without threads like this? This sounds like a case of your Node.js database driver hiding the exact same behaviour described here within C code.

If the wire protocol for the driver is published, then you can write a 100% async driver for it. I.e. no threads blocking, ever. In fact, I already did this for redis and vert.x (I will dig out the code for this some time).

If you are dealing with something where you don't know what the wire protocol is and you just have a blocking client library to play with (e.g. JDBC - JDBC is, by definition blocking - see the JDBC API), then you can't do much but to wrap the blocking api in an async facade and limit the number of threads that block at any one time. This is exactly what we do in vert.x. We accept the fact that many libraries in the Java world are blocking (e.g. JDBC) so we allow you to use them by running them on as a worker. This is one area where we differ from node.js. Node.js makes you run everything on an event loop. This is just silly for some things, e.g. long running computations (remember the Fibonacci number affair?), or calling blocking apis. With vert.x you run "event-loopy" things on the event loop but you can run "non event-loopy" things on a worker. It's a hybrid.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#55

Post by purplefox »

bascule wrote: post #47
Animus7 wrote: post #8

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 sol…

"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 h…

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).

Re: Vert.x – JVM Polyglot Alternative to Node.js

#57

Post by jbooth »

dap wrote: post #43
dap wrote: post #30

Earlier quoted context omitted.

But you have to dedicate a thread to sendFile() (by nature).

(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 t…

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.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#58

Post by ricardobeat »

batista wrote: post #36
Uchikoma wrote: post #18

Finagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.

> What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. Would you call Node.js's MySQL drivers "production quality"?

Being non-existent and being production quality or not are very different things. BTW there are hundreds of node apps in production.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#59

Post by almost »

purplefox wrote: post #56
almost wrote: post #46

req.response.sendFile('webroot/' + file); !!!! I'll have file='../../secret.txt' thanks

Yes, of course in a real web server you'd make sure you do the checks ;) The documentation actually mentions this point explicitly :)

I'm pretty sure I don't want to use a web server by people who think a 5 line demo that gives unrestricted access to the hosts file system is the best way to show off it's capabilities. Sorry, but that's just stupid.

Re: Vert.x – JVM Polyglot Alternative to Node.js

#60

Post by tlrobinson »

Uchikoma wrote: post #18

Finagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.

There was no MySQL driver for Node when it was first created. You have to start somewhere.
Post reply on HN