Re: GWT application freezes when new version is deployed while using it

To add to Stephen's points,

- Using legacy mode, or keep the last set of RPC files around (so you
have N & N-1) should let the users fail gracefully w/o deserialization
errors. Then you can check the app version number (say put this check
on your async interfaces) and prompt for reload.

- App Engine lets you deploy multiple versions of your app to
<version>.myapp.appspot.com. If you had an 'A' and 'B' version, and
alternated them each release, you could use the graceful shedding to
move everyone from A.myapp.appspot.com to B.myapp.appspot.com and then
turn off A (or at least have no more entry points to A).

- To prevent this in our enterprise apps we have taken the slightly
draconian policy of a 30min UI timeout. There is a listener that
resets the timer every time there is a click interaction with the UI.
Thus, if someone leaves the app untouched for 30min, they get a locked
out modal with a button to reload.

- Finally, do the cut over for your app in hours of nadir load. We do
ours in the wee hours on the weekend, so nobody should be using it at
the time.

Sincerely,
Joe

On Feb 29, 11:36 am, Stephen Haberman <stephen.haber...@gmail.com>
wrote:
> > Is there a clean way to *not* require the user to refresh the page?
>
> Everything Thomas said is right, and I'll chime in with my own experience.
> Basically:
>
> - If you use IsSerializable and no type-name elision you won't have to keep
> old GWT RPC policy files around between builds (the legacy serialization
> policy will handle new/old clients as long as your DTOs don't have changes,
> which for frequent builds is probably more often the case--AFAIK this makes
> GWT RPC comparable to RF in handling non-breaking-changes to the DTOs)
>
> - As Thomas said, handle IncompatibleRemoteServiceExceptions for when DTOs
> do have breaking changes
>
> - As Thomas said, handle 404s in runAsync onFailures (or just not use async
> loading if your app is small enough :-)
>
> - Have a clean switch between new/old servers (e.g. if you have 10 servers,
> then start 10 new servers, and slowly turn off the old ones, you'll run
> into problems, which I walked through in a blog post [1]). Ideally you can
> immediately switch from the old server(s) to the new.
>
> Having seamless deployments is surprisingly hard for GWT apps--although I
> don't think the problems are unique to GWT vs. regular webapps, its
> approach to perfect caching highlights the problems of new/old
> servers/clients trying to talk nicely to each other. I'd be interested in
> hearing internal/Google best practices for this sort of stuff, although it
> looks like Thomas has already inferred a lot of it by watching how the
> Google Groups UI behaves.
>
> - Stephen
>
> [1]http://draconianoverlord.com/2010/07/07/gwt-seamless-upgrades.html
>
>
>
>
>
>
>
> On Thursday, January 5, 2012 6:39:37 AM UTC-6, Kyle Baley wrote:
>
> > Now that I've determined our problem, I have another question. Is there a
> > clean way to *not* require the user to refresh the page?
> On Thursday, January 5, 2012 6:39:37 AM UTC-6, Kyle Baley wrote:
>
> > Now that I've determined our problem, I have another question. Is there a
> > clean way to *not* require the user to refresh the page?
> On Thursday, January 5, 2012 6:39:37 AM UTC-6, Kyle Baley wrote:
>
> > Now that I've determined our problem, I have another question. Is there a
> > clean way to *not* require the user to refresh the page?
> On Thursday, January 5, 2012 6:39:37 AM UTC-6, Kyle Baley wrote:
>
> > Now that I've determined our problem, I have another question. Is there a
> > clean way to *not* require the user to refresh the page?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.