Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing semantics between cache(int) and replay(int) #3016

Closed
dlew opened this issue Jun 10, 2015 · 4 comments
Closed

Confusing semantics between cache(int) and replay(int) #3016

dlew opened this issue Jun 10, 2015 · 4 comments

Comments

@dlew
Copy link

dlew commented Jun 10, 2015

It seems misleading that replay(1).refCount() != cache(1), especially when replay().refCount() == cache().

It's especially odd because each one cannot mimic the behavior of the other - cache() has no variant that limits the number of items to replay, whereas replay() has no variant that allows you to hint how large the ReplaySubject should be.

I see that this has been covered before (#1591, #2913), but I still feel like something could be done to clear up the matter. Not exactly sure what - maybe all it'd take is not having the javadoc for cache() reference replay().

@fabianeichinger
Copy link

I agree that caching a limited number of elements using cache() would be handy sometimes, but it is important to note that replay().refCount() does not behave equal to cache() in all situations.

For example:

int i = 0; // actually a field or static
Observable<Integer> cached = Observable
            .defer(() -> Observable.just(i++, i++))
            .cache();
cached.subscribe(i -> System.out.println("sub 1: " + i));
cached.subscribe(i -> System.out.println("sub 2: " + i));

prints

sub 1: 0
sub 1: 1
sub 2: 0
sub 2: 1

compared to

int i = 0; // actually a field or static
Observable<Integer> replayed = Observable
            .defer(() -> Observable.just(i++, i++))
            .replay().refCount();
replayed.subscribe(i -> System.out.println("sub 1: " + i));
replayed.subscribe(i -> System.out.println("sub 2: " + i));

which results in

sub 1: 0
sub 1: 1
sub 2: 2
sub 2: 3

@dlew
Copy link
Author

dlew commented Jun 12, 2015

That's interesting; I didn't know that refCount actively unsubscribes from the base subscription, though I guess it wouldn't really work otherwise.

@akarnokd
Copy link
Member

If the upstream terminates, all subscribers go away and refCount starts from zero again.

I'm proposing the autoConnect() operator in #3023 so you can use replay(10).autoConnect() for now instead of a bounded cache().

@akarnokd
Copy link
Member

I hope this problem has been clarified via the javadoc and the new autoConnect operator in release 1.0.14.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants