4 ms·

>2. Platform threads + non-blocking APIs = painful to use, scales to many connections Wow, I have written a substantial amount of non-blocking IO since around

by xxs 4y ago

>2. Platform threads + non-blocking APIs = painful to use, scales to many connections Wow, I have written a substantial amount of non-blocking IO since around java 1.4.2 (when it actually became stable). It was not much harder to use at all (compared to io streams). The issues w/ buffering/scalability and internal scheduling will be exactly the same with green threads.

deleted 4y ago
[deleted]
twic 4y ago
Me too, and that's not correct. Firstly, the idea that NIO is "not much harder to use at all (compared to io streams)" is wild on its own. People built Netty (and XNIO) precisely because of how awkward NIO is to use. But secondly, there are common, useful patterns that are trivial with streams and extremely awkward with asynchronous I/O. For example, here's some code which queries a database and streams the results to the client as JSON: OutputStream responseBody; // assume you get this from somewhere try (JsonGenerator json = Json.createGenerator(responseBody)) { json.writeStartArray(); try (Connection connection = openDatabaseConnection()) { ResultSet results = connection.prepareStatement("select first_name, last_name from users").executeQuery(); while (results.next()) { json.writeStartObject(); json.write("first_name", results.getString("first_name")); json.write("last_name", results.getString("last_name")); json.writeEnd(); } } json.writeEnd(); } It does not load all the data into memory, it does not buffer all the JSON in memory, it automatically handles backpressure (if the socket blocks on a write, it will pause reading results from the database), it releases its resources cleanly if an exception occurs, and it's fourteen lines of very simple code. You cannot do anything like this with an asynchronous API.
- xxs 4y ago
  >It does not load all the data into memory, it does not buffer all the JSON in memory, it automatically handles backpressure (if the socket blocks on a write, it will pause reading results from the database), This particular feels a lot better with streams as jdbc is blocking by nature and it has no other options. However, the simple code has its own issues. It closes the output stream on finishing the read, unless the output is really large it wastes quite a lot (the tcp/tlc handshakes, authentication/authorization/etc.). If the output is large enough (implied by not loading the json, and not having where clause in the sql) it exposes the database server to all the denial of service when the clients don't read fast enough, i.e. the database has to support as many connections as the frontend java.

by xxs 4y ago

deleted 4y ago

[deleted]

twic 4y ago

Me too, and that's not correct. Firstly, the idea that NIO is "not much harder to use at all (compared to io streams)" is wild on its own. People built Netty (and XNIO) precisely because of how awkward NIO is to use. But secondly, there are common, useful patterns that are trivial with streams and extremely awkward with asynchronous I/O. For example, here's some code which queries a database and streams the results to the client as JSON: OutputStream responseBody; // assume you get this from somewhere try (JsonGenerator json = Json.createGenerator(responseBody)) { json.writeStartArray(); try (Connection connection = openDatabaseConnection()) { ResultSet results = connection.prepareStatement("select first_name, last_name from users").executeQuery(); while (results.next()) { json.writeStartObject(); json.write("first_name", results.getString("first_name")); json.write("last_name", results.getString("last_name")); json.writeEnd(); } } json.writeEnd(); } It does not load all the data into memory, it does not buffer all the JSON in memory, it automatically handles backpressure (if the socket blocks on a write, it will pause reading results from the database), it releases its resources cleanly if an exception occurs, and it's fourteen lines of very simple code. You cannot do anything like this with an asynchronous API.

xxs 4y ago
>It does not load all the data into memory, it does not buffer all the JSON in memory, it automatically handles backpressure (if the socket blocks on a write, it will pause reading results from the database), This particular feels a lot better with streams as jdbc is blocking by nature and it has no other options. However, the simple code has its own issues. It closes the output stream on finishing the read, unless the output is really large it wastes quite a lot (the tcp/tlc handshakes, authentication/authorization/etc.). If the output is large enough (implied by not loading the json, and not having where clause in the sql) it exposes the database server to all the denial of service when the clients don't read fast enough, i.e. the database has to support as many connections as the frontend java.