Announcement

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

    Problem with rest datasource fetchdata call in 4.0d

    Version: LGPL 4.0d 2013-04-16
    Browser: Firefox 20.0.1

    I upgraded an existing project to SmartGWT 4.0d.
    I've cleaned out the browser cache, removed war/sc/<project> and recompiled the project.

    I'm using a fetchdata call from a rest datasource to seed a list of grids in a section stack.

    The DSRequest is getting to the server and firebug confirms the server is sending back valid XML to the browser yet it doesn't get to the response object...

    Code:
     projDS.fetchData(null, new DSCallback() {
      public void execute(DSResponse response, Object rawData, DSRequest request) {
        System.out.println("In Project fetchData response.");
        Record[] recs = response.getData();
        System.out.println("Project response length: "+ recs.length);
        for (Record project : response.getData())
        {
          System.out.println("In LatestView loop - project: " + project.toString());
          String side = project.getAttributeAsString("tbl_side");
          if (side.equals("left"))
          {
            leftSection.add(project, new CellClicker());
          }
          else
          {
            rightSection.add(project, new CellClicker());
          }
        }
      }
    });
    The messages in execute() never get posted to the dev console.

    The Developer Console output
    Code:
    12:54:44.519:INFO:Log:initialized
12:54:46.155:WARN:Log:New Class ID: 'DataView' collides with ID of existing object with value 'function DataView() {
    [native code]
}'.  Existing object will be replaced.
This conflict would be avoided by disabling ISC Simple Names mode.  See documentation for further information.
12:54:46.412:INFO:Log:isc.Page is loaded
12:55:22.959:TMR9:WARN:Log:TypeError: _7 is null
Stack from error.stack:
    DataSource._handleClientOnlyReply/_6() @ AfClone/sc/modules/ISC_DataBinding.js:501
    DataSource._handleClientOnlyReply() @ AfClone/sc/modules/ISC_DataBinding.js:502
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:238
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:296
    anonymous() @ AfClone/sc/modules/ISC_DataBinding.js:1230
    $wnd.isc.RPCManager.fireReplyCallback() @ :249
    [c]RPCManager.fireReplyCallbacks() @ AfClone/sc/modules/ISC_DataBinding.js:1231
    [c]RPCManager.performOperationReply() @ AfClone/sc/modules/ISC_DataBinding.js:1230
    RPCManager._performTransactionReply() @ AfClone/sc/modules/ISC_DataBinding.js:1226
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:238
    Timer._fireTimeout() @ AfClone/sc/modules/ISC_Core.js:967
    unnamed() @ AfClone/sc/modules/ISC_Core.js:963
    unnamed() @
    The stack trace
    Code:
    12:55:23.588 [ERROR] [AfClone] 12:55:22.959:TMR9:WARN:Log:TypeError: _7 is null
Stack from error.stack:
    DataSource._handleClientOnlyReply/_6() @ AfClone/sc/modules/ISC_DataBinding.js:501
    DataSource._handleClientOnlyReply() @ AfClone/sc/modules/ISC_DataBinding.js:502
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:238
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:296
    anonymous() @ AfClone/sc/modules/ISC_DataBinding.js:1230
    $wnd.isc.RPCManager.fireReplyCallback() @ :249
    [c]RPCManager.fireReplyCallbacks() @ AfClone/sc/modules/ISC_DataBinding.js:1231
    [c]RPCManager.performOperationReply() @ AfClone/sc/modules/ISC_DataBinding.js:1230
    RPCManager._performTransactionReply() @ AfClone/sc/modules/ISC_DataBinding.js:1226
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:238
    Timer._fireTimeout() @ AfClone/sc/modules/ISC_Core.js:967
    unnamed() @ AfClone/sc/modules/ISC_Core.js:963
    unnamed() @ 


com.smartgwt.client.core.JsObject$SGWT_WARN: 12:55:22.959:TMR9:WARN:Log:TypeError: _7 is null
Stack from error.stack:
    DataSource._handleClientOnlyReply/_6() @ AfClone/sc/modules/ISC_DataBinding.js:501
    DataSource._handleClientOnlyReply() @ AfClone/sc/modules/ISC_DataBinding.js:502
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:238
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:296
    anonymous() @ AfClone/sc/modules/ISC_DataBinding.js:1230
    $wnd.isc.RPCManager.fireReplyCallback() @ :249
    [c]RPCManager.fireReplyCallbacks() @ AfClone/sc/modules/ISC_DataBinding.js:1231
    [c]RPCManager.performOperationReply() @ AfClone/sc/modules/ISC_DataBinding.js:1230
    RPCManager._performTransactionReply() @ AfClone/sc/modules/ISC_DataBinding.js:1226
    [c]Class.fireCallback() @ AfClone/sc/modules/ISC_Core.js:238
    Timer._fireTimeout() @ AfClone/sc/modules/ISC_Core.js:967
    unnamed() @ AfClone/sc/modules/ISC_Core.js:963
    unnamed() @ 

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    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(Unknown Source)
    I believe the GWT plugin (1.20) is up to date.
    Any suggestions on how to go about debugging this?
    Tags: None
    #2
    If you want to debug it, use the *Debug modules.

    Just a note that this code is involved in processing clientOnly responses. So this suggests that you are either actually using a clientOnly DataSource (and not a RestDataSource as you stated), or you have the cacheAllData property set.

    Comment

      #3
      It was the CacheAllData. I guess I was taking advantage of a bug.
      I must have misread 3.0 the doc. I assumed that caching occurred after the first server fetch

      Thanks.

      Comment

        #4
        Yes, that's how cacheAllData works - one fetch to the server, then clientOnly responses are issued from the cache from then on (unless the cache expires - see cacheAllMaxAge).

        Comment

          #5
          In that case, there may be a problem here.

          I had cacheAllData set to true.
          It was sending the request to the server but it looks like it didn't set the cache.

          I used it this way so filters on the listgrids were client side.
          When I commented it out, I was able to get the data but it populated a single listgrid with all the data (should have been 8 listgrids).

          Comment

            #6
            Yes, we suspected you actually needed that behavior..

            There's no general problem with cacheAllData (lots of automated tests for that, all passing).

            If you use the *Debug modules you can get more information. Capturing a stack trace from another browser might also reveal more details (this one looks a little odd - don't know what that _06() means at the top of the stack).

            Alternatively, if you can put together runnable code that reproduces the problem, we can look at that.

            Comment

              #7
              Yes. I definitely need that behavior.

              I was invalidating the DS cache just prior to the fetchData call.
              Code:
                  projDS.invalidateCache();
    projDS.fetchData(null, new DSCallback() {...
              I had tried commenting it out thinking it might be a timing issue but I was still seeing the crash.

              If you're using cacheAllData and it's behaving as it should then it's on my end (sigh).

              I'll see if I can come up with a standalone based solely on the fetchData callback above.
              If I can get the data and have it execute the loop (or not) would be all I'd need.

              At least it's been narrowed down a bit.
              Thanks again.

              Comment

                #8
                I ran this with IE8 and it did not crash but did come back and say that response.getData().length was 0.

                I also loaded the war file into a tomcat 7 server and that didn't crash either when I brought it up with firefox.
                It didn't display anything from the loop so I assume the response length there was 0 as well.
                I need to look into how to write to tomcat's logs.

                Given that there's apparently nothing in the cache when execute runs, could this be a timing issue?

                Also, can you tell me what version of GWT you're using in your test environment?
                One of the things I did in the 4.0d upgrade was get the latest GWT plugins.

                com.google.gwt.eclipse.sdkbundle_2.5.0.v201212122042-rel-r42

                You mentioned above about having no clue what the "_06()" was in the stack trace.
                Could this be that I'm using a newer version of GWT that may have issues?

                I'm going to create a new project using 4.0d with just the standalone fetchData loop.
                I want to rule out any upgrade cruft.

                I'm not sure if creating a clientonly standalone case will work here.
                Given that the functionality in question (cacheAllData) seems to be closely related.
                If it works, I'm not sure what that tells me.

                Comment

                  #9
                  We test with multiple GWT versions. It's not especially likely the GWT version is influencing behavior - GWT is not in the stack.

                  It's always possible it's a timing issue, but not an obvious one (which would be caught by our automated tests).

                  Continuing to isolate the problem is the best approach if you don't want to get into the source code.

                  Comment

                    #10
                    While trying to come up with a standalone test (see attached), I got this crash and stack trace.

                    It seems to want records of type ListGridRecord to be stored in the cache.

                    If I change the record types to ListGridRecord in the DataSource, I don't get the crash.

                    Code:
                    13:11:04.069 [ERROR] [CacheAllData] 13:11:04.060:WARN:Log:setCacheData(): DataSource cache data is expected to be an array of ListGridRecords. This allows the data to be displayed as expected in ListGrids bound to this dataSource.

com.smartgwt.client.core.JsObject$SGWT_WARN: 13:11:04.060:WARN:Log:setCacheData(): DataSource cache data is expected to be an array of ListGridRecords. This allows the data to be displayed as expected in ListGrids bound to this dataSource.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    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.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:338)
    at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:219)
    at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:571)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNativeVoid(ModuleSpace.java:299)
    at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeVoid(JavaScriptHost.java:107)
    at com.smartgwt.client.util.SC.logWarn(SC.java)
    at com.smartgwt.client.data.DataSource.setCacheData(DataSource.java:4574)
    at com.ctest.client.CacheAllData$1.&lt;init&gt;(CacheAllData.java:67)
    at com.ctest.client.CacheAllData.&lt;init&gt;(CacheAllData.java:37)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:475)
    at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:385)
    at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
    at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
    at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
    at java.lang.Thread.run(Unknown Source)
                    Attached Files

                    Comment

                      #11
                      Sorry about the red herring above.
                      Not sure why it was crashing when Record was used.

                      Anyway, I have a testcase that will demonstrate the crash when CacheAllData is set to true (at least it should).

                      When I run the standalone test against a RestDataSource, I get the following...
                      Code:
                      11:15:33.419 [ERROR] [RestCacheAllData] Uncaught exception escaped

com.google.gwt.core.client.JavaScriptException: (null) @com.smartgwt.client.data.DataSource::getClientOnlyResponse(Lcom/smartgwt/client/data/DSRequest;[Lcom/smartgwt/client/data/Record;)([Java object: com.smartgwt.client.data.DSRequest@24082451, Java object: [Lcom.smartgwt.client.data.Record;@12046689]): null
    at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:249)
    at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:571)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:279)
    at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)
    at com.smartgwt.client.data.DataSource.getClientOnlyResponse(DataSource.java)
    at com.test.client.RestCacheAllData$1.getClientOnlyResponse(RestCacheAllData.java:49)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
    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.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:338)
    at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:219)
    at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:571)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:279)
    at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)
    at com.google.gwt.core.client.impl.Impl.apply(Impl.java)
    at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:242)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
    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(Unknown Source)
                      Please let me know what you find or if you need anything else.
                      Attached Files

                      Comment

                        #12
                        Have you tries this against the latest patched build? It looks like its fixed.

                        Comment

                          #13
                          I tried this against the April 30th (yesterday's) build.
                          Should I give one later than that a shot?

                          /*
                          * Browser: FireFox 20.0.1
                          * GWT dev plugin: 1.20
                          * SmartGWT build: 4.0d April 30, 2013
                          * Java 7 Update 21
                          *
                          * This test should fail in the RestDataSource override
                          * of getClientOnlyResponse. The serverData coming into the
                          * routine is fine. It crashes in the subsequent "super" call.
                          * At least it crashes when I run it. Also note that the cached
                          * data appears to be fine.
                          *
                          */

                          Comment

                            #14
                            That would be fine, if that's the version that was actually running - can you double check? Be sure to clear cache, run a GWT compile, and run in compiled mode (which you also need to do to take a stack trace for the JS error, if it still occurs).

                            You can also use the instructions in the FAQ to make sure you are really loading the new version.

                            Comment

                              #15
                              I built and compiled the test case from scratch this morning.
                              I flushed the browser cache before running the test as well.

                              I'll update the libs to today's build and get back to you once I check out the FAQ you're referring to.

                              Any general idea what the title of the question/answer is that I should be looking for?

                              If not, I'll find it and get back to you.

                              Comment

                              Previous 1 2 template Next
                              Working...
                              X