fix(cache): get correct caching behavior

[benlesh]

This is an initial pass at fixing the cache operator. There is still a lot to do, but this is merge-worthy IMO. Ideally, the cache operator would use the lift mechanism. Also this is not well optimized as it is introducing a lot of closures. But it works, and that's the point for now.

fixes #1628

[benlesh]

(finally) lol

[coveralls]

Coverage increased (+0.01%) to 96.361% when pulling fc1509c on blesh:cache2 into 0a6c4e8 on ReactiveX:master.

[benlesh]

Merged after quick review from @kwonoj

[staltz]

Kind of sad that it's all "rx4", but you know that already.

[benlesh]

@staltz, yeah, I'll iterate on it.

[trxcllnt]

@Blesh Is the difference between this and source.multicast(() => new ReplaySubject()).refCount() that this only recycles the ReplaySubject when the source emits an error (as opposed to when the subscriber count drops to 0)?

To phrase it another way, it seems like this operator now permanently leaks memory until the source emits an error. If true, this troubles me greatly.

[benlesh]

Where is the leak? Can it be demonstrated?

[trxcllnt]

@Blesh

// push 1000000 numbers into cache's ReplaySubject
const source = Observable.range(0, 1000000).cache();
const subscription = source.take(100000).subscribe({
  complete() {
    console.log(`cache's ReplaySubject now has 100000 values`);
  }
});

// cache now has a reference to a ReplaySubject with 100000 values.
// in order to release the reference for GC, I have to set source to null,
// but I can't since it's is a const.

subscription.unsubscribe(); // <-- this should do it

[matthewwithanm]

Is there documentation anywhere about how cache() is supposed to work now?

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.