Is it possible that client-only DataSources aren't released from memory? We are using client-only DataSources and also if I am using destroy() or markForDestroy(), memory size is growing and growing. I therefore suspect the client-only DataSources...
Announcement
Collapse
No announcement yet.
X
-
If you destroy() a clientOnly DataSource and all components bound to it are either destroyed or bound to other DataSources, there should not be a leak.
If you try to create a test case showing a memory leak please be sure to read the Memory Leaks overview in the reference doc. We receive a lot of test cases that do not show memory leaks.
-
Code:DataSource testDS = new DataSource("testDS"); testDS.setClientOnly(Boolean.TRUE); IButton requestBtn = new IButton("Fill DS"); requestBtn.addClickHandler(new ClickHandler() { @Override public void onClick(ClickEvent event) { // Records RecordList records = new RecordList(); for (int i = 0; i < 1000000; i++) { ListGridRecord record = new ListGridRecord(); record.setAttribute("Country", "C" + i); records.add(record); } testDS.invalidateCache(); testDS.setCacheData(records.toArray()); } }); IButton destroyDSButton = new IButton("Destroy DS"); destroyDSButton.addClickHandler(event -> testDS.destroy());
Comment
-
Sorry Isomorphic, but with that answer I can't handle my problem.
Of course I read the Memory leaks overview before. But there is nothing about client-only DataSources in it. It is just a small piece of code which I posted, and with that you can reproduce the problem of increasing memory size.
There is no error in my code and also no warning or something in the console. I think the problem is the client-only DataSource and the cache data which is not released when I set new cache data to the existing DataSource. How can I release the old CacheData so that I can free up my memory?
Comment
-
What we said:
Please see the Memory Leaks overview as previously indicated. Memory exhaustion leading to an error is the only valid sign of a leak. Anything else can be just temporary churn.
Seeing the browser's memory use rise dramatically after a given operation does not demonstrate a memory leak. It's normal for browser memory usage to fluctuate wildly, because the browser will generally not reclaim resources immediately, and in some cases will not reclaim resources until memory is nearly exhausted. Some browsers will also build up pools of resources for later re-use.
The only way to demonstrate a real memory leak is to demonstrate memory exhaustion: showing that the browser memory usage rises until all memory is exhausted and errors begin to occur. No other pattern of increasing memory usage - no matter how large - is considered evidence of a leak, because the browser may suddenly reclaim very large amounts of memory after memory usage rises to a certain trigger point. Memory exhaustion is the only way to demonstrate a real memory leak.
To get to the next step, create a minimal, ready-to-run test case that shows memory exhaustion.
Comment
Comment