Release 1.0.RC1

[viktorklang]

What needs to happen in order for us to be able to ship a release candidate of Reactive Streams 1.0?

Thoughts:

1. We first have to release Release 0.4.0.M2 #83
2. We need to port/create the TCK
3. We need to update and elaborate on the documentation
4. We need to have 1, preferably more, implementations ready who pass the TCK so we know we're coving most/all the bases with the spec

@reactive-streams/contributors please add thoughts as comments

[alexandru]

On number 4) I think it's very important that there are at least 2 implementations available, since there's nothing like actually implementing a spec for highlighting problems. Shouldn't be a problem to wait for 2 solid implementations, right?

[jbrisbin]

Reactor 2.0 already implements this version of the spec. /cc @smaldini

[viktorklang]

@alexandru I thought "2" first but I would say that "2+" would be a requirement for the final version, I think an RC can be shipped with having "1+" passing the TCK.

And it looks like it's going to be possible to ship the RC1 with "2+" since @jbrisbin & @smaldini has Reactor 2.0 going strong and the akka team should be able to migrate to 0.4.0 shortly.

[smaldini]

reactive-streams branch in reactor gh is on track, still suffers an issue with competing demand signaling and event flow that only reveals on online CI (I can't sleep anymore this is killing me). I've implemented the latest firehose changes to see if it would help but this still happens to me. All the samples I've seen so far from @rkuhn or @benjchristensen don't really address the buffering rules around consumer without demand (which is quite core to the spec).

I think a lot of implementations will deal with this issues, alongside with Merge/Parallel operations issues :D

[viktorklang]

@smaldini "the buffering rules around consumer without demand" - could you elaborate on what you mean by that?

[alexandru]

As a note, I'm also working on an implementation that's fairly strong, but still needs work. Have been waiting on the TCK for 0.4.0.

[danarmak]

I'm in a similar situation with future-streams: I'll update it to 0.4 and make sure it passes the TCK, once 0.4 and the TCK are more or less finalized.

[alexandru]

I have seen that the folks from RxJava made progress in 0.20.0-RC1 for adding back-pressure, though they aren't yet implementing the interfaces, so yeah, good times ahead :-) /cc @benjchristensen

[viktorklang]

@alexandru Yeah, I'm super stoked, fingers crossed we've ironed out virtually all issues that were reported and we've minimized the "moving parts" to get to a minimal core/spec.

[smaldini]

@viktorklang specifically this:
https://gist.github.com/rkuhn/505bcac2caddbff6b47e#file-bounded-scala-L34

In real scenario and according to the rules (and to allow for slower rate), it needs to be overflowed somewhere until subscriber next request that will pull first and increase the capacity with the remaining.

[alexandru]

Folks - as an idea, a mailing list or place where we could discuss
implementation issues would be nice :-)

On Thu, Jul 17, 2014 at 5:53 PM, Stephane Maldini [email protected]
wrote:

@viktorklang https://github.com/viktorklang specifically this:
https://gist.github.com/rkuhn/505bcac2caddbff6b47e#file-bounded-scala-L34

In real scenario and according to the rules (and to allow for slower
rate), it needs to be overflowed somewhere until subscriber next request
that will pull first and increase the capacity with the remaining.

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

Alexandru Nedelcu
https://bionicspirit.com

[rkuhn]

@smaldini: that benchmark code was done specifically for rate-detaching high-throughput code, if the intention is to not drop elements then the code will have to look quite differently (i.e. actually propagating demand as intended). For real code you can take a look at the Akka implementation: we only run the processing for an element if we actually have both supply and demand in the same spot.

[smaldini]

@rkuhn yup understood, don't get me wrong I think the example is quite fantastic and actually made me think about the subscription slightly differently. But yeah this is the kind of issues implementations will have to deal with probably and its not an easy one. Thanks for the pointer onto Akka impl., its worth a read too! 👍

[viktorklang]

@alexandru We tried that, but my personal opinion is that it's better to keep things in the open and as close to the project as possible, so opening an issue and discussing it seems like the lowest-overhead option.

[danarmak]

@alexandru That's a good idea, shall we make one on Google Groups or would you prefer a different forum?

[benjchristensen]

I'm fine with those 4 requirements for releasing 1.0RC1, but I'd like to have at least 3 implementations capable of interacting with each other before we call 1.0 final.

The goal is to have RxJava there this summer (next 6-10 weeks hopefully). Since RxJava 1.0 can't break all of its existing interfaces, it will require a bridge between RxJava and the Reactive Stream interfaces, but this will be a simple RxJava module that adds the bridge for interop. RxJava core is adopting the semantics of Reactive Streams so bridging the interfaces should be sufficient for interop and compatibility as the request(long n) behavior will match the spec.

[viktorklang]

Hooking together 3+ implementations would definitely be a worthy
graduation-anyone want to come up with a good exam?
On Jul 17, 2014 7:01 PM, "Ben Christensen" [email protected] wrote:

I'm fine with those 4 requirements for releasing 1.0RC1, but I'd like to
have at least 3 implementations capable of interacting with each other
before we call 1.0 final.

The goal is to have RxJava there this summer (next 6-10 weeks hopefully).
Since RxJava 1.0 can't break all of its existing interfaces, it will
require a bridge between RxJava and the Reactive Stream interfaces, but
this will be a simple RxJava module that adds the bridge for interop.
RxJava core is adopting the semantics of Reactive Streams so bridging the
interfaces should be sufficient for interop and compatibility as the request(long
n) behavior will match the spec.

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

[jbrisbin]

It would be good to include a TCK of some sort that tests this interoperability. It would have a set of circumstances that would simulate common integration points and the various permutations could be tested by having implementation authors provide a shim between the TCK Publisher and their implementation.

I think using a ServiceLoader for Publisher and one for Subscriber and creating a test scope dependency for a specific *-interop-tck module from the implementation would work. The test could then match publishers with subscribers to see how they interoperate.

[DougLea]

A few notes about potential java.util.concurrent tie-ins: I'm hoping that we include reactive-streams APIs as one part of extending async/reactive support. The other parts will probably include one or more primitive "TaskEmitter" interfaces (for, among other cases, uncontrollable sources), utilities for hooking CompletableFutures to IO, timers, and JDK8 parallel streams, some standard way way to bridge the sticky-exception-fluent CompletionStage API with onSuccess / onFailure style APIs, and a few other things. I plan to post something about these one of these days on the concurrency-interest list.

[smaldini]

BTW on the TCK side, I hope we can also verify some asynchronous behavior at scale with heavily repeated concurrent testing and reasonable volume (1M > onNext). StreamSubscription can be subject to race condition in particular and I think that was one of the most difficult challenge in the implementation we are running on Reactor.

[benjchristensen]

@DougLea That's great to hear. I look forward to the concurrency-interest post and building future revisions of Rx against these new interfaces.

[viktorklang]

Sounds great,
Let's talk about how we can migrate the end product into a JDK9 proposal.
On Jul 17, 2014 7:27 PM, "DougLea" [email protected] wrote:

A few notes about potential java.util.concurrent tie-ins: I'm hoping that
we include reactive-streams APIs as one part of extending async/reactive
support. The other parts will probably include one or more primitive
"TaskEmitter" interfaces (for, among other cases, uncontrollable sources),
utilities for hooking CompletableFutures to IO, timers, and JDK8 parallel
streams, some standard way way to bridge the sticky-exception-fluent
CompletionStage API with onSuccess / onFailure style APIs, and a few other
things. I plan to post something about these one of these days on the
concurrency-interest list.

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

[viktorklang]

Consuming infinite & hot sources is a good example. More thoughts?
On Jul 17, 2014 8:37 PM, "Stephane Maldini" [email protected]
wrote:

BTW on the TCK side, I hope we can also verify some asynchronous behavior
at high volume with heavily repeated concurrent testing and reasonable
volume (1M > onNext). StreamSubscription can be subject to race condition
in particular and I think that was one of the most difficult challenge in
the implementation we are running on Reactor.

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

[boboyada]

why not use jdk8' stream /lambda/function/etc,standing on Shoulders of Giants;

[viktorklang]

@boboyada anyone is free to create a library/Reactive Streams impl that can lift j.u.s.Stream into a Publisher. Reactive Streams is not intended to be end-user API, please refer to the README

[viktorklang]

@reactive-streams/contributors Alright everybody, I think it's time to take this to the next level. Can we get 1.0.0-RC1 out ASAP?

[benjchristensen]

👍 on releasing 1.0.0-RC1

[viktorklang]

@reactive-streams/contributors

Everything is now in place for shipping 1.0.0.RC1,
once we release 1.0.0.RC1 I propose that all implementations switch over to the TCK for 1.0.0.RC1 so that we get confirmation that things pass, then we create a PoC subproject that demonstrates the interoperability between the different conforming implementations.

I'd like to ship 1.0.0.RC1 ASAP, so please vote within 7 days!

[ldaley]

Is the intention that this is a real RC? That is, there are no changes planned between RC and final release?

[viktorklang]

Yes. No changes expected, only bugfixes reported against the RC.
On Nov 25, 2014 2:19 AM, "Luke Daley" [email protected] wrote:

Is the intention that this is a real RC? That is, there are no changes
planned between RC and final release?

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

[viktorklang]

@reactive-streams/contributors I propose to publish Reactive Streams 1.0.0.RC1 on friday the 19th of December. Then we make a push to get implementations on top of 1.0.0.RC1 as soon as possible, then we cut 1.0.0 when we see that we have enough implementations successfully on 1.0.0.RC1.

Sounds good? Sounds bad? Let your voice be heard :)

[benjchristensen]

👍

[viktorklang]

@benjchristensen Awesome! Sadly the time table slipped a bit, but I think we can cut the RC1 this week :)

[viktorklang]

@smaldini I think we are in RC1-shape code wise, we have examples, we have a TCK, we have the examples passing the TCK, we have multiple implementations and we've polished the spec.
Stephane, if you want to, I'd love for you to do us the honor of publishing the 1.0.0.RC1—is that something you'd be able and willing to do sometime this week? Don't hesitate to decline if it is inconvenient for you to publish! :)

@reactive-streams/contributors We, the Reactive Streams SIG, has achieved something remarkable here in a quite short amount of time. I am extremely honored to have the privilege of working together with all of you.

Happy Holidays everyone!

[smaldini]

I'm going to deploy it of course, give me a couple dozen minutes, I've been poisoned with wine and chocolate :)

[viktorklang]

No stress. :-)

Cheers,
√
On 27 Dec 2014 19:34, "Stephane Maldini" [email protected] wrote:

I'm going to deploy it of course, give me a couple dozen minutes, I've
been poisoned with wine and chocolate :)

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

[smaldini]

It's on maven central. I'm fixing our tests now which fail on multiple subscribe case :)

[smaldini]

Quick Question about idempotent subscriptions, I have a simple fix which is "use the Stream#broadcast() (transform a cold stream in hot stream) operation at the end of the helper publisher". This because the publisher stream is unicast in that test suite (Iterable Stream create a unique registration cursored on the iterablee). Do I really need to enforce it on the cold stream or does the test expect an hot stream ?

[viktorklang]

Which test is failing for you?

Cheers,
√
On 27 Dec 2014 20:40, "Stephane Maldini" [email protected] wrote:

Quick Question, I have a simple fix which is "use the broadcast()
operation at the end of the helper publisher" because the stream is unicast
in that case (Iterable Stream create a unique registration). Do I really
need to enforce it on the cold stream or do the test expect an hot stream ?

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

[smaldini]

spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation

[viktorklang]

Hmm, open an issue and I'll have a look when I have a computer handy and a
couple of minutes to spare.

Could you push the RC1 tag? Thanks!

Cheers,
√
On 28 Dec 2014 03:05, "Stephane Maldini" [email protected] wrote:

spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

[smaldini]

Damn I thought it was pushed, I'll do it later on when I get back close to my machine.

Sent from my iPhone

On 28 Dec 2014, at 8:23 am, Viktor Klang (√) [email protected] wrote:

Hmm, open an issue and I'll have a look when I have a computer handy and a
couple of minutes to spare.

Could you push the RC1 tag? Thanks!

Cheers,
√
On 28 Dec 2014 03:05, "Stephane Maldini" [email protected] wrote:

spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

—
Reply to this email directly or view it on GitHub.

[viktorklang]

Great, thanks. I'll draft some form of annoucement so we can get people
onto it and give feedback before 1.0.0.final

On Sun, Dec 28, 2014 at 3:21 PM, Stephane Maldini [email protected]
wrote:

Damn I thought it was pushed, I'll do it later on when I get back close to
my machine.

Sent from my iPhone

On 28 Dec 2014, at 8:23 am, Viktor Klang (√) [email protected]
wrote:

Hmm, open an issue and I'll have a look when I have a computer handy and
a
couple of minutes to spare.

Could you push the RC1 tag? Thanks!

Cheers,
√
On 28 Dec 2014 03:05, "Stephane Maldini" [email protected]
wrote:

spec212_mustNotCallOnSubscribeMoreThanOnceBasedOnObjectEquality_specViolation

—
Reply to this email directly or view it on GitHub
<
https://github.com/reactive-streams/reactive-streams/issues/84#issuecomment-68196043>

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#84 (comment)
.

Cheers,
√

[smaldini]

Done