Announcement

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

    #16
    To clarify further - just that won't help. There's been no breakage anywhere in this area for weeks. That's why we're recommending trying someone else's environment.

    Comment


      #17
      Im the only developer within 2000 miles of my location so thats not real practical

      Comment


        #18
        Shouldn't take very long for an email to cover that distance :)

        And presumably you can create a clean environment on another box or VM as well.

        Seriously, if you want to solve this problem, we would recommend following our troubleshooting advice. You could alternatively start turning on diagnostics like the "ResultSet" log category in your JPA example to see if we can get more detail on what's going on. But this is probably useless, because all signs point to some kind of corrupted environment.

        Comment


          #19
          I'm so at wits end with you guys. We paid good money for service, and I get told to send an email? I just recreated this dev environment a week ago. Why I get nothing but arrogance and snide remarks from you, I really dont understand. It couldn't possibly take that long to take the JPADS modifcation I sent you and deploy it and verify that this is unique to my environment. Rather than just assuming your framework is bug free, as I have found several in the past few months.

          This is rediculous..................

          Comment


            #20
            If you're going to insist on this route (which again we believe will be less effective) we can run your test.

            Please provide the rest of the required details (GWT version, browser(s) affected, OS). Note we will always need these.

            Also please let us know what the ResultSet log says as previously indicated.

            Also, side note: someone else from your team recently had us chasing a bug report and then reported that it was an environment problem. This is one reason why we think you may have a corrupted environment since you all have a similar Maven setup. Also, you did find a bug in a very obscure subsystem. This test case again exercises very basic functionality.

            Comment


              #21
              It was actually a GWT bug, due to not clearing cache when running in Hosted Mode.

              I have my browser set not to cache, and have not ever had that issue.

              Browser - Firefox 11.0, IE 8
              OS - Win XP SP 2
              GWT 2.4

              ResultSet log
              Last edited by jpappalardo; 24 Sep 2014, 09:37.

              Comment


                #22
                Thanks for letting us know - so you're all set then?

                Generally we don't trust the browser options to "not cache" because we've seen instances where they cache anyway.

                Comment


                  #23
                  To be certain I manually cleared my caches and tried again.



                  Only the first fetch occurs, as if the rest of the code does not exist. Ultimately the only way to see that this exception is occurring is to catch it.
                  There is nothing in the server logs, dev console output, rpc tab, or firebug to indicate that anything has wrong. And the exception that is caught has absolutely no information. The only indication being that only 1 of the 3 fetches occurs. Hence I only end up being bound to the first datasource.
                  Last edited by jpappalardo; 24 Sep 2014, 09:37.

                  Comment


                    #24
                    So just to sanity check:

                    1. the simple JPA test case works fine - this was corrected by clearing cache

                    2. your actual app still isn't doing subsequent fetches, but this turns out to be due to an Exception being thrown, but the Exception message is blank

                    What this suggests is that your code calls SGWT framework code, everything goes fine and the request is initiated, then code that runs *after* you do the fetch crashes - it could be, for instance, createStarepoint() in updateMissionData().

                    So two suggestions:
                    1. since the Exception message is blank, try getClass().getName() to find out it's basic type and ask it to printStackTrace()

                    2. if you've added an UncaughtExceptionHandler you may be interfering with SmartGWT's default error reporting, try removing this
                    Last edited by Isomorphic; 25 Apr 2012, 10:22.

                    Comment


                      #25
                      I have no uncaught exception handler. The JPA test does not work deployed. Both cases only execute without consequence in GWT Hosted Mode. If you read through the log carefully, all it has done is issue the request for fetch. All functions properly once data is received.

                      Comment


                        #26
                        ? What did this refer to then: "It was actually a GWT bug, due to not clearing cache when running in Hosted Mode."

                        This is all still accurate and reflects the right next steps.

                        What this suggests is that your code calls SGWT framework code, everything goes fine and the request is initiated, then code that runs *after* you do the fetch crashes - it could be, for instance, createStarepoint() in updateMissionData().

                        So two suggestions:
                        1. since the Exception message is blank, try getClass().getName() to find out it's basic type and ask it to printStackTrace()

                        2. if you've added an UncaughtExceptionHandler you may be interfering with SmartGWT's default error reporting, try removing this
                        Note about createStarepoint(), this is code that runs after the fetch is initiated (by getRange()) and before data returns. Calling getRange() is not synchronous - when called with a ResultSet that doesn't have the requested rows, it initiates a fetch and returns loading markers in the array.

                        So the fact that your code works at all is presumably because you call updateMissionData() once to initiate the fetch then later again to actually work with the data once it's loaded. And the fact that you're getting an Exception suggests your code crashes when called when data is not yet loaded.

                        Comment


                          #27
                          Also, about a month ago your app got horked because someone added a deprecated version of json.js to the project - do you have any similar third-party JS code now? That could interfere with ResultSet.

                          Comment


                            #28
                            Just to clarify the 3 calls I am demonstrating are the first requests to the 3 ResultSets, which are each bound to a different datasource, for data being performed in an override of onInit(). All other requests once the data is cached are of no consequence. They operate as expected. I have a lot of use of updateCaches being invoked via Realtime Messaging, and so inserts updates and removals are tracked successfully by this map widget, either invoked locally or by a remote user. But I can only get this to successfully occur for all 3 datasources by catching the exception that is coming out of the initial getRange() calls.

                            Here is the exception class info
                            Last edited by jpappalardo; 24 Sep 2014, 09:37.

                            Comment


                              #29
                              ArrayStoreException definitely suggests your code after the getRange() call is crashing due to some interaction with the Array full of loading markers that getRange() returns when data hasn't been loaded yet. Have you been able to get a stack trace yet (we suggested printStackTrace)?

                              And again - any third party JS? That could cause even correct code to crash.

                              Comment


                                #30
                                I have reformatted my handler methods to demonstrate that I don't do anything if the ResultSet does not have data cached



                                I'm not sure how to get Exception.printStackTrace() to output to anything.
                                Last edited by jpappalardo; 24 Sep 2014, 09:38.

                                Comment

                                Working...
                                X