-
Notifications
You must be signed in to change notification settings - Fork 57
MemoryLeak #595
Comments
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This still a problem. |
+1 |
it seems there is a Problem for input-elements. I reduced @betschwa example, to only print out the inputfield. The memory usage is printed on command-line. to make it more visilbe, i use a List of 1000 Input-Fields.
|
I appreciate the effort to diagnose this problem. I'll try to investigate but unfortunately I've had limited spare time to devote to Kweb lately. I'll look into it today. |
Spent a while staring at code. I think @chucky2002's code is helpful but is putting the browser under such load that it maybe be triggering other problems. I think the root of the issue may be Kweb's listener mechanism, specifically the way that adding a listener (eg. to a KVal) returns a handle which must be used to remove the listener later - which is very error prone. I think the solution may be to replace this with a more robust mechanism where listeners have a hierarchy of "owners" - which can be deleted en-masse when no-longer needed. I'll continue to work on this as time allows. I've also stopped the rather obnoxious auto-closing of "stale" issues. |
Currently, this bug is causing a significant problem for me.
|
The library probably contains a memory leak. If KVar is updated regularly, the server consumes more and more memory until the OutOfMemoryError occurs.
I have created a sample project to reproduce this behavior.
https://github.com/betschwa/KWebMemoryProblemTest
Here is the job for updating a KVar:
Here is the display:
The text was updated successfully, but these errors were encountered: