Announcement

Collapse
No announcement yet.
X
Collapse
  • Page of 1
  • Filter
  • Time
Clear All
new posts
Previous template Next
    #1

    TreeGrid.setData(Tree) question

    SmartClient Version: v9.1p_2014-03-20/PowerEdition Deployment (built 2014-03-20)
    GWT 2.5.1
    IE-11

    I followed the example on the Isomorphic Wiki on doing refreshes with a ListGrid using the DataSource to fetch and then doing a listgrid.setData().

    I'm seeing instances of ListGridRecord(s) being accumulated with every TreeGrid.setData(Tree). With a fixed data set of 22k compressed being sent every time, after 70 refreshes the browser falls over and hangs.

    Should I be clearing the TreeGrid first before doing a TreeGrid.setData(Tree)?
    Tags: None
    #2
    Assuming you are hand-creating Tree of ResultTree instances, you do have to destroy() those.

    Comment

      #3
      I am assembling the Tree manually, here is my DSCallback:

      Code:
      DataSource treeGridDataSource = treeGrid.getDataSource();
            treeGridDataSource.setShowPrompt(Boolean.FALSE);
            treeGridDataSource.fetchData(criteria, new DSCallback() {
                @Override
                public void execute(DSResponse dsResponse, Object data, DSRequest dsRequest) {
                    if(DEBUG) GWT.log("PivotTableGrid.treeGridDataSource.DSCallback()");
                    Tree newTree = new Tree();
                    newTree.setRootValue(0);
                    newTree.setModelType(TreeModelType.PARENT);
                    newTree.setIdField("id");
                    newTree.setParentIdField("pid");


                    Record [] recordList = dsResponse.getData();
                    TreeNode[] nodeList = new TreeNode[recordList.length];

                    for(int m=0; m<recordList.length; m++){
                        nodeList[m] = new TreeNode(recordList[m].getJsObj());
                    }
                    newTree.setData(nodeList);
                    GWT.log(" pre data add: treeGrid size " + treeGrid.getData().getData().length);
                    treeGrid.getData().destroy();
                    treeGrid.setData(newTree);
                    GWT.log("post data add: treeGrid size " + treeGrid.getData().getData().length);

                    TREE_COUNTER++;
                    int count = treeGrid.getRecords().length;
                    if(count > 0) {
                        if(openState != null && nodeCount == treeGrid.getData().getAllNodes().length) treeGrid.setOpenState(openState);
                        else treeGrid.getData().openFolder(Tree.nodeForRecord(treeGrid.getRecords()[0]));
                    }
                    treeGrid.markForRedraw();
                    if(DEBUG) GWT.log("PivotTableGrid.treeGridDataSource.DSCallback() done.");

                }
            });
      You can see my attempt at destroying the Tree as you suggested. Is that correct above?

      I still have a growing set of the following classes that increase with every refresh, the call to treeGrid.getData().destroy() has no impact with every refresh on the following objects:
      com.smartgwt.client.widgets.grid.ListGridRecord
      com.smartgwt.client.widgets.grid.ListGridField
      com.smartgwt.client.data.Record
      com.smartgwt.client.widgets.tree.TreeNode

      The smartgwt objects above keep growing and growing with every refresh.

      Is there another way of destroying the Tree that I'm not doing correctly? Or is there any other data management operations I need to do to clear all the data in the browser before adding new data to the TreeGrid?

      Comment

        #4
        I've added some more debug information:
        Code:
        DataSource treeGridDataSource = treeGrid.getDataSource();
            treeGridDataSource.setShowPrompt(Boolean.FALSE);
            treeGridDataSource.fetchData(criteria, new DSCallback() {
                @Override
                public void execute(DSResponse dsResponse, Object data, DSRequest dsRequest) {
                    if(DEBUG) GWT.log("PivotTableGrid.treeGridDataSource.DSCallback()");
                    Tree newTree = new Tree();
                    newTree.setRootValue(0);
                    newTree.setModelType(TreeModelType.PARENT);
                    newTree.setIdField("id");
                    newTree.setParentIdField("pid");


                    Record [] recordList = dsResponse.getData();
                    TreeNode[] nodeList = new TreeNode[recordList.length];

                    for(int m=0; m<recordList.length; m++){
                        nodeList[m] = new TreeNode(recordList[m].getJsObj());
                    }
                    newTree.setData(nodeList);
                    GWT.log("-------------"+REQUEST_COUNTER+"-------------");
                    GWT.log(" pre data add: treeGrid size " + treeGrid.getData().getData().length);
                    treeGrid.getData().destroy();
                    GWT.log("      destroy: treeGrid size " + treeGrid.getData().getData().length);
                    treeGrid.setData(newTree);
                    GWT.log("post data add: treeGrid size " + treeGrid.getData().getData().length);


                    TREE_COUNTER++;
                    int count = treeGrid.getRecords().length;
                    if(count > 0) {
                        if(openState != null && nodeCount == treeGrid.getData().getAllNodes().length) treeGrid.setOpenState(openState);
                        else treeGrid.getData().openFolder(Tree.nodeForRecord(treeGrid.getRecords()[0]));
                    }
                    treeGrid.markForRedraw();
                    if(DEBUG) GWT.log("PivotTableGrid.treeGridDataSource.DSCallback() done.");

                }
            });
        and the output looks like this as we refresh everytime:
        Code:
        Loading module: com.anstca.tz.Main
  Top URL: http://127.0.0.1:8080/tzw/home.htm?gwt.codesvr=127.0.0.1:9997
  User agent: IE
  Remote host: 127.0.0.1:49382
  Tab key: 3404
  Session key: Ik8MZO^e+gYc-L?%
INFO: Module com.anstca.tz.Main has been loaded
INFO: addStyleName is not supported. Calling setStyleName instead
INFO: -------------1-------------
INFO:  pre data add: treeGrid size 0
INFO:       destroy: treeGrid size 0
INFO: post data add: treeGrid size 626
INFO: -------------2-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------3-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------4-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------5-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------6-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------7-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------8-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------9-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------10-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------11-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------12-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------13-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------14-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------15-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------16-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------17-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------18-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------19-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------20-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
        The data remains constant and does not change, we are simply doing a refresh with the same data.

        In the SmartGWT dev console, the RPC requests for each fetch is talking longer and longer, each subsequent request adds almost 1 second to the Elapsed Time with each request.

        Here is the server log entry for the data being sent with each request, verifying the data remains the same on the refresh:
        === 2014-03-28 11:42:02,631 [ec-2] INFO Compression - /tzw/com.anstca.tz.Main/sc/IDACall: 115762 -> 22064 bytes
        Last edited by JLivermore; 28 Mar 2014, 07:43.

        Comment

          #5
          on the 41st refresh, the browser is showing a warning that says:

          The server did not recieve the data that was sent to it. Please see the documentation for isc.RPCResponse.STATUS_MAX_POST_SIZE_EXCEEDED

          I checked the server and client Javadoc that shipped with the version we are on about RPCResponse and there is nothing in the client or the server Javadoc on RPCResponse.STATUS_MAX_POST_SIZE_EXCEEDED?

          The browser is hung at this point and the last successful fetch Operation in the DevConsole shows an Elapsed Time of 19990ms.

          Comment

            #6
            here is the log from the client as the browser hung:
            Code:
            INFO: -------------41-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
data: "The server did not receive the data that..."[136]}
data: "The server did not receive the data that..."[136]}
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
	at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:105)
	at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
	at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
	at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:293)
	at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547)
	at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
	at java.lang.Thread.run(Thread.java:744)
INFO: -------------43-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------45-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
INFO: -------------46-------------
INFO:  pre data add: treeGrid size 626
INFO:       destroy: treeGrid size 626
INFO: post data add: treeGrid size 626
ERROR: Remote connection lost
com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote connection lost
	at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:308)
	at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547)
	at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
	at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.SocketException: Connection reset by peer: socket write error
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
	at java.io.DataOutputStream.flush(DataOutputStream.java:123)
	at com.google.gwt.dev.shell.BrowserChannel$ReturnMessage.send(BrowserChannel.java:1310)
	at com.google.gwt.dev.shell.BrowserChannel$ReturnMessage.send(BrowserChannel.java:1315)
	at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:296)
	at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547)
	at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
	at java.lang.Thread.run(Thread.java:744)
INFO: Unloading module com.anstca.tz.Main (com.anstca.tz.Main)

            Comment

              #7
              Docs for STATUS_MAX_POST_SIZE_EXCEEDED are right here.

              That's probably not something to look at. It's probably a symptom of the browser running out of memory.

              Your destroy() call is OK, so the memory is being leaked in another way. It could:

              1. you have logging enabled in the Developer Console that is basically logging all of the data being transfered

              2. you have "Track RPCs" checked in the Developer Console - same effect

              3. you have some other development tool open that causes the leak - including possibly GWT development mode - so try it with no tools open

              Comment

                #8
                here are my findings thus far, IE-11 on Windows 7 is still responsive, but the memory is growing slowly. IE-8 on XP fell over not even an hour into the test. No debug tools connected to the client or server. just observing memory size in Task Manager.

                IE-11 on Windows 7
                starttime: 4:36 134,552k
                check : 5:26 146,208k
                check : 5:42 151,492k


                IE-8 on XP
                starttime: 4:36 163,184k
                checkin : 5:27 176,868k

                browser is frozen with a Warning pop-up: The server did not recieve the data that was sent to it. Please see

                the documentation for isc.RPCResponse.STATUS_MAX_POST_SIZE_EXCEEDED. Clicked ok, thought the browser was hung, but it

                was very very slow. The pop-up went away and then came back. I clicked OK again. I can see the memory racing in a loop from

                186,184 up to 201,248 and then back down again and again like in a loop. When the warning pop-up comes up, and you click OK, the

                memory stabalizes and then begins to climb again back to the loop like behavior.

                Comment

                  #9
                  We're not sure why you're doing these tests. Memory is obviously leaking, but we already explained the likely causes - analysis of the rate of leaking for a false leak is not very useful.

                  Comment

                    #10
                    IE-8 had an issue, I still need to test IE-9 on XP with SmartGWT 4.1. The purpose of these tests are to verify the issue we had back on the older version of SmartGWT 2.x:

                    http://forums.smartclient.com/showthread.php?t=25074

                    Comment

                      #11
                      OK - we're not sure how that's related, but whenever you get a chance, the next step is to look at the probable causes we listed in post #7.

                      Comment

                        #12
                        Oh yes, my last test results had all debug and development tools disabled and was executed like a production build.

                        IE-11 on Windows7 worked fine.
                        IE-8 on XP fell over and ran out of memory less than 1 hour into the test.

                        I'm going to test IE-9 on XP soon. Thanks for the feedback.

                        Comment

                          #13
                          What we think you'll find is that IE9 also doesn't leak, and something is unusual/broken about the IE8 test environment that you are using, and you won't be to reproduce the issue on a clean install.

                          Comment

                            #14
                            Yes, I agree, the IE-8 test I did seems odd.
                            I will retest IE-8 and IE-9 again.

                            I hope that is the case. :)

                            Comment

                            Previous template Next
                            Working...
                            X