Memory leak for dispatcher

[flamurey]

Hi,

I don't now why but my app have memory leak. By using chrome I detect into heap dump what dispatcher undicrectly contains all actions with payloads. My app frequently load large data and dispatching it.

[MikeRyanDev]

Interesting. Do you think you might be able to reproduce it in a Plunker or in a separate repo?

[flamurey]

https://plnkr.co/edit/pzODIm

watching memory profiler you will see as used memory increasing

[asarode]

Has any progress been made on this?

[dchacke]

+1. I have been running into issues with memory as well and am curious if it has to do with this.

[MikeRyanDev]

I originally left this issue open because we were using a custom built subject for tracking actions. Recent versions of @ngrx/store are just using a BehaviorSubject and the queue scheduler. If this memory problem still persists, this is most likely a bug in rxjs. Thanks!

[michaelcleary]

I'm using rxjs/store (2.2.1) in an application that puts some fairly large result sets into the store. Unfortunately because of this memory leak the application crashes the browser as the store after a few data requests. If the bug is with rxjs, is it possible something could be done to work around it in ngrx?

[mfahlen]

I'm also seeing memory leaks using @ngrx/store version 2.2.1. It looks like dispatched actions aren't garbage collected. Any help looking into this issue would be greatly appreciated.

[MikeRyanDev]

@michaelcleary @mfahlen

I have two theories:

1. Are you using @ngrx/store-devtools? The devtools are going to keep all actions to make recomputing of states possible. There is an option to only retain the last n actions if this is case.
2. Are you using ngrx-store-logger? If you are using ngrx-store-logger (or something similar to log actions to the console) then the actions won't be able to be garbage collected until the console is cleared.

Let me know if this is not the case and I'll reopen the issue.

[michaelcleary]

No, did initially think that could be the cause, so took both those out and found it was exactly the same. Even with the example app you can see that the heap is steadily growing with each request and this is apparently because the _subscriptions array inside _dispatcher retains every QueueAction (as shown in the original post).

…

On 17 December 2016 at 00:28, Mike Ryan ***@***.***> wrote: @michaelcleary <https://github.com/michaelcleary> @mfahlen <https://github.com/mfahlen> I have two theories: 1. Are you using @ngrx/store-devtools? The devtools are going to keep all actions to make recomputing of states possible. There is an option to only retain the last n actions if this is case. 2. Are you using ngrx-store-logger? If you are using ngrx-store-logger (or something similar to log actions to the console) then the actions won't be able to be garbage collected until the console is cleared. Let me know if this is not the case and I'll reopen the issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#167 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB_x3QXgqlfE3HcbIxijSiG9wNE2s_p5ks5rIyy7gaJpZM4JHHOk> .

[MikeRyanDev]

@Blesh Any ideas? Code path that reproduces this:

const dispatcher = new BehaviorSubject({ type: 'INIT' });

dispatcher.observeOn(queue).subscribe();

Previous actions pushed into the dispatcher subject won't be released anymore.

[josh-sachs]

I believe I am also being affected by this issue. It is quite severe. Can anyone recommend a previous version of ngrx/store that isn't impacted by this while a resolution is found?

[MikeRyanDev]

For reference, I've opened up an issue about this on the rxjs repo: ReactiveX/rxjs#2244

@kudoz83 There isn't a previous version of @ngrx/store unaffected by this issue. Observing the action stream on a queue prevents action reentrancy.

[MikeRyanDev]

Fixed in rxjs v5.0.3