reactive-streams

reactive-streams-jvm

Java2015–2020

reactive-streams / reactive-streams-jvm

reactive-streams-jvm

Reactive Streams Specification for the JVM

Languages & Compilers Learning & Reference

Explore on GitHub Read Hacker News discussions

4Distinct people

5Mentions

0Explicit recommenders

4.9KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Reactive Streams Specification for the JVM

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

omnistreams/omnistreams-spec · linked in 3 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year5 dated mentions

Observed mentions: 2015-05-07 12:03:50 UTC to 2020-05-14 00:35:51 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	1	1
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	2

What Hacker News says

5 sources

anderspitman·May 14, 2020

> In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read() Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems. As for the dependencies-as-URLs, I don't mind it, and may prefer it. I've been experimenting with minimizing my dependencies lately, and vendoring them in git submodules. It's worked fairly well. [0]: https://github.com/pull-stream/pull-stream [1]: https://github.com/reactive-streams/reactive-streams-jvm [2]: https://github.com/omnistreams/omnistreams-spec

In Deno 1.0

apitman·Apr 23, 2020

This is awesome. The new streaming stuff is particularly interesting to me, and it's very impressive that you managed to implement it with no protocol changes. I have a couple questions. Please forgive any misconceptions as I've never used capnproto myself, since all the streaming I've done has to work in the browser, and as far as I know capnproto doesn't work over WebSocket or WebRTC transports. But I've long been impressed with and inspired by capnproto and sandstorm. Main question: is there a reason you opted for traditional window flow control a la TCP, as opposed to "request-N" style like in reactive streams[0] (see rsocket[1] for a great implementation)? So with request-N, a server->client stream would look something like this: interface MyInterface { streamingCall @0 (callback :Callback) -> (requester :Requester); interface C

Read the rest

allback { sendChunk @0 (chunk :Data) -> (); } interface Requester { request @0 (n :int) -> (); } } And the server will only ever send as much data as has been requested by the client with requester calls. This results in really elegant flow control that takes into account both the network, and the client's capacity to consume, without the necessity of tracking windows. The receiver simply calls request(1) each time it processes a message. If you want a buffer you can just start with an assumed N=10, 100 etc. I've found this worked really well when implementing omnistreams[2], which is basically a very thin streaming/multiplexing layer for WebSockets, since WS doesn't have any flow control. (fibridge[3] is a good example of it in action). I started with a window-style but once I learned about reactive streams the request model was much easier to reason about for me. [0]: https://github.com/reactive-streams/reactive-streams-jvm [1]: https://github.com/rsocket/rsocket [2]: https://github.com/omnistreams/omnistreams-spec [3]: http://iobio.io/2019/06/12/introducing-fibridge/

In Cap'n Proto 0.8: Streaming flow control, HTTP-over-RPC, fibers

anderspitman·Jun 1, 2019

Interesting. I do tend to favor protocols that are a bit lower level and more flexible for composing higher-level functionality. Though this does sound pretty complicated to implement using only what capnproto offers right now. Would there be a way to jury rig "request(n)" backpressure as described in reactive streams[0] (also implemented by RSocket[1]) on top of capnproto? That's what I'm using for omnistreams and it's proven very simple to reason implement and reason about. [0] https://github.com/reactive-streams/reactive-streams-jvm [1] http://rsocket.io/ [2] https://github.com/omnistreams/omnistreams-spec

In Why We’re Switching to gRPC

agentgt·Dec 18, 2016

The actor model is not far from the AMQP pub/sub model. I have talked about this on Stackoverflow [1]. The real advantage for Akka would be not having to go over the wire when forking (aka recursing on a problem). That being said AMQP has so many advantages particularly because there are so many clients and you could in theory have a thin facade over any AMQP library that does routing locally for certain queues (we actually do this for our Java message bus). It is also because of message reilability. If you use AMQP you can have a very heterogenous environment. Infact I even wrote some consumers recently in Rust to replace some Java ones but are not production ready (still waiting for heartbeat support). Yeah you could use Akka as a consumer but here is the shocker it actually isn't that good if your messages need to be reliable. This is

Read the rest

because most Akka rabbitmq consumers are auto ACK. This is because RabbitMQ is actually a pull model when using prefetch + manual ack. Akka is not and will drop messages. The reactive streams model [2] (rxjava2 and future akka stuff) is not as flexible nor as powerful as AMQP as there is no per message ACK but rather an ACK for a group of messages. Yes you could set the request/demand rate to 1 but that would hurt performance. Again AMQP shines for message reliability. [1]: http://stackoverflow.com/questions/5693346/when-to-use-actor... [2]: https://github.com/reactive-streams/reactive-streams-jvm

In Using RabbitMQ and AMQP for Distributed Work Queues in Node.js

rozza·May 7, 2015

For evidence of people in production now, you will find more users of RxJava which has been providing similar functionality for a while (including backpressure support). I think this convention is one for the future and this release marks the start of adoption. I think the hope is that more implementations will come in the future and one goal is to allow the simple connection of reactive streams and allow the building complex distributed systems. Also interestingly it looks like this concept might make it into jdk9 as Flow - https://github.com/reactive-streams/reactive-streams-jvm/iss...

In Reactive Streams for the JVM hits 1.0.0