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

  • RPC Response to fetch incomplete JSON

    1. SmartGWT version 3.0 (although the error also occurs when upgrading to 12.0)
    2. Testing using chrome version 70.0.3538.77 (occurs in other browsers)
    3. Not a server-side problem. It's an appengine application. We logged the json right before it is written, and it is complete.
    4. The JSON in the response is incomplete. A screenshot of the SC Dev Console is attached (dev-console.png) . The raw response on the bottom is scrolled to the end. You'll see the JSON ends abruptly which causes the frontend error. I've removed the url and peoples names and things of that sort.
    Click image for larger version

Name:	dev-console.png
Views:	1
Size:	244.0 KB
ID:	255780
    5. Attached console stacktrace ( console-log.txt )
    6. Attached is the code receiving the RPC response according to the dev console ( ) which extends EntityLayout
    7. This issue only occurs after upgrading appengine to java 8 runtime, so I don't know if it's a bug in SmartGWT or something we need to change in the code. It's worth noting that the amount of bytes that are left off is inconsistent.

  • #2
    Have you looked with browser tools to see if the response from the server is in fact incomplete? That would be the definitive test. Logging on the server is not at all definitive.

    The basic question: is there any SmartGWT code involved in this RPC at all? You didn't include any server-side logs from our system; that's always required.

    Assuming the server response is indeed truncated, if you are writing JSON directly into a stream, it's probably a missing flush() call in your code.


    • #3
      We don't use SmartGwt on the server side. Instead, we use HttpServlets. Here is the function sending the json from the backend ( sendRsponse.txt ). The string logged in the function shows the json in full form with ending braces and the function doesn't throw an IOException when the problem occurs.
      I've also attached our DataSource function that sets up the operation bindings( datasource.txt ).

      Please let me know if you need more info.


      • #4
        This continues to be non-definitive. Again, check the browser’s built-in tools to look at the response, typically you can open these by pressing F12. We’re pretty certain you’ll find that the actual response is truncated before it reaches the browser.

        Since you aren’t using our server code, you need to look at your own code to figure out how you’re sending a truncated response, and again, it’s probably lack of a call to flush() on a stream *somewhere in the processing chain*, which means, it could be a filter servlet that is involved in processing in addition to the code you’ve shown.