0.20.0 Release

[benjchristensen]

Version 0.20.0-RC3 has passed the Netflix API production canary tests for 20+ hours with good performance numbers and no functional issues we're aware of.

Despite much that can continue to be worked on, there doesn't appear to be anything that must be done before 0.20.0 is released.

I would however like to know from other users, particularly those on Android, if 0.20.0-RC3 is working correctly. Please test and report back.

Also, this is the last chance to dispute any of the design or API decisions in 0.20 before they are finalized and we start our work on 1.0 release candidates.

Thank you all.

[zsxwing]

@benjchristensen I try to understand the assumptions for Producer.request. Here is my thought:

• happen-before relation: subscriber.onStart -> 1st request -> emit 1st event -> 1st onNext -> 2nd request. "->" means happen-before relation.
• The data source, such as OnSubscribeRange and OnSubscribeFromIterable, does not need to handle the currency of Producer.request because observeOn will dispatch requests to the same scheduler.

Please correct me if I made a mistake.

[benjchristensen]

happen-before relation

Mostly correct, except that in RxJava since "request pull" behavior is optional, there is nothing preventing an Observable.OnSubscribe emitting events before a request occurs. The onStart will always happen-before, but then it branches into two paths:

• Observable.OnSubscribe that calls setProducer where a request happens-before emissions
• Observable.OnSubscribe that does not call setProducer where emission can happen before or after a request (the request is ignored).

because observeOn will dispatch requests to the same scheduler.

This is not correct for observeOn, but is correct for subscribeOn. The observeOn case can result in work being "stolen" and run by the observeOn Scheduler rather than wherever the Observable.OnSubscribe originally started it.

You can see how subscribeOn does this here: https://github.com/Netflix/RxJava/blob/82c634fdf93cc6608c3bb94645ae14b2232abd74/rxjava-core/src/main/java/rx/internal/operators/OperatorSubscribeOn.java#L90

observeOn on the other hand could "steal" the work and execute it directly (see here https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/internal/operators/OperatorObserveOn.java#L184) if the upstream Observable is synchronous.

[dpsm]

@benjchristensen have been using on a development branch and everything remains working fine within the scope of what I use from rxjava an the android extensions.

[samueltardieu]

I replaced RxJava 0.19.6 with 0.20.0-RC3 in cgeo for Android. I got hit by:

E/cgeo    (  394): java.lang.RuntimeException: Timed out waiting for value. File a bug at github.com/Netflix/RxJava
E/cgeo    (  394):  at rx.internal.operators.BlockingOperatorToIterator$2.take(BlockingOperatorToIterator.java:97)
E/cgeo    (  394):  at rx.internal.operators.BlockingOperatorToIterator$2.hasNext(BlockingOperatorToIterator.java:73)
E/cgeo    (  394):  at rx.internal.operators.BlockingOperatorToIterator$2.next(BlockingOperatorToIterator.java:83)
E/cgeo    (  394):  at rx.observables.BlockingObservable.single(BlockingObservable.java:348)
E/cgeo    (  394):  at rx.observables.BlockingObservable.first(BlockingObservable.java:165)
E/cgeo    (  394):  at cgeo.geocaching.SearchResult.parallelCombineActive(SearchResult.java:317)

However, it looks like this timeout is arbitrary and is going to be removed before 0.20: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/internal/operators/BlockingOperatorToIterator.java#L93

// TODO remove this timeout and logging before final release of 0.20
Notification<? extends T> n = notifications.poll(10000, TimeUnit.MILLISECONDS);
if(n == null) {
    System.err.println("Timed out waiting for value. File a bug at github.com/Netflix/RxJava");
    throw new RuntimeException("Timed out waiting for value. File a bug at github.com/Netflix/RxJava");
} else {
    return n;
}

So I won't file a bug about it, as the operations may take a long time (lengthy network operations on a limited number of threads). Apart from that, everything went fine.

[Yarikx]

Played some time with latest version of RxJava on current application, but without using any new (introduced in 20.*) api.
Everything seems to works fine, except strange issue I had before (that I'm sure is pretty much the same as #1234)
Everything else works fine for me.

[benjchristensen]

@samueltardieu Thanks for the feedback. As long as the reason for the RuntimeException was that your code had a legit reason to take longer than 10 seconds, then that's fine. That code has been left in to help us find hangs due to bugs.

@Yarikx Thanks ... I'm most concerned right now about existing functionality working as expected, so that's exactly the feedback I need. If you can provide more information on #1234 we can reopen it.

[benjchristensen]

@dpsm Thanks for the confirmation.

[Yarikx]

Ok. I will try to write reproducible code little bit later.
In my case this problem occurs in some special combination of observables
that run through different schedulers.
On Jul 29, 2014 9:08 PM, "Ben Christensen" notifications@github.com wrote:

@samueltardieu https://github.com/samueltardieu Thanks for the
feedback. As long as the reason for the RuntimeException was that your
code had a legit reason to take longer than 10 seconds, then that's fine.
That code has been left in to help us find hangs due to bugs.

@Yarikx https://github.com/Yarikx Thanks ... I'm most concerned right
now about existing functionality working as expected, so that's exactly the
feedback I need. If you can provide more information on #1234
#1234 we can reopen it.

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

[daschl]

@benjchristensen I updated to 0.20 and my harness doesn't report any errors, so thumbs up

[benjchristensen]

Thanks @daschl for the test and confirmation.

[benjchristensen]

Version 0.20.0-RC4 is released with further fixes and enhancements: https://github.com/Netflix/RxJava/releases/tag/0.20.0-RC4

This code ran successfully for 18+ hours in a Netflix production canary before release.

There are however still some issues that concern me that are causing non-deterministic hangs and failures of unit tests. In particular #1536.

Outstanding items: https://github.com/Netflix/RxJava/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.20

[yogurtearl]

Any chance of getting #1542 fixed for 0.20.0?

[benjchristensen]

Yes definitely. This is a regression during the 0.20 series.