You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you open the browser window, and then exit it, the process memory runs amok. Again, this is primarily driven by frequent state changes - if you use my original example and reduce the ticker interval, it does not occur. However, if you create a lot of elements dependent on that state (e.g. 1000 buttons but a 0.1s timer), it happens again. The issue I have in practice is that I believe the leak still occurs in a normal application if you exit the browser window at an inconvenient time - and this is the closest example I've been able to come up with.
Assuming that the leaks in fact occur because the client disconnects at an inconvenient time, the solution is probably to add some cleanup steps to the shared view dispatcher. From what I remember, no such cleanup happens at the moment.
I've stumbled upon another memory leak, this time in
SharedClientStateServer
. Try this:If you open the browser window, and then exit it, the process memory runs amok. Again, this is primarily driven by frequent state changes - if you use my original example and reduce the ticker interval, it does not occur. However, if you create a lot of elements dependent on that state (e.g. 1000 buttons but a 0.1s timer), it happens again. The issue I have in practice is that I believe the leak still occurs in a normal application if you exit the browser window at an inconvenient time - and this is the closest example I've been able to come up with.
Originally posted by @mx781 in #509 (reply in thread)
The text was updated successfully, but these errors were encountered: