3

I am using AppEngine with Restlet to serve my data to a GWT app in the browser as client. The Restlet-GWT edition uses GWT-RPC serialization as the transport format underneath. GWT-RPC serialization relies on the shared source between client and server to serialize/deserialize.

Now, after adding a new property to one of the shared source classes, de-serialization started failing. The AppEngine server processed the request correctly with response HTTP 200 / OK and was sending out a correctly serialized object. The client choked each time.

After awhile I figured out that the browser was trying to deserialize a cached copy of my object (without the newly added property) and so de-serialization in the browswer failed.

Now the question : why is the browser using a cached copy if the server is being hit anyhow ?

IMO, this defeats the purpose/advantages of caching, the server and network resources are being consumed and the fresh result is not used ? In case the browswer decides to use a cached copy, I would expect no round-trip to the server.

thx !

koma
  • 6,486
  • 2
  • 27
  • 53
  • I run into this issue when deploying a new version to AppEngine too, what are my options to prevent this from happening ? – koma Jun 12 '12 at 09:10
  • and yes, I did stop/start the app, recompiled and all... – koma Jun 12 '12 at 19:17

1 Answers1

1

Your browser is keeping the javascript compiled by GWT for you application in cache.

Easy solution, do a hard refresh of your page a couple of times (ctrl + F5, or cmd + shift + R).

If you want to prevent this, see this question

Community
  • 1
  • 1
jonasr
  • 1,876
  • 16
  • 18
  • so the browser is caching the compiled javascript and not the payload of the XHR request ? That sounds like a valid explanation ! – koma Jun 13 '12 at 13:55