Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Client-only DataSources with memory problems?

    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...

    #2
    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.

    Comment


      #3
      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());
      I just have to press the Fill-DS-Button several times and the memory size of the application in Windows Task Manager is growing fast up to 500 MB and more. It makes no difference if I am using IE11 or Chrome. Also invalidateCache() or testDS.destory() have no effect on the memory size. Is it not recommended to use Client-Only-DataSources for large DataSets? What am I doing wrong?

      Comment


        #4
        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.

        Comment


          #5
          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


            #6
            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.
            The docs:
            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.
            Not sure how we can make this any more clear. You have not demonstrated a memory leak. There is no reason to discuss code changes because you have not demonstrated a memory leak.

            To get to the next step, create a minimal, ready-to-run test case that shows memory exhaustion.

            Comment

            Working...
            X