Description of problem: Through some non-trivial flow, which I can't recall exactly, I got a blank screen, and in server.log I saw: 2016-02-11 16:01:45,616 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/ovirt-engine/webadmin]] (ajp--127.0.0.1-8702-5) Exception while dispatching incoming RPC call: com.google.gwt.user.client.rpc.SerializationException: Can't find the serialization policy file. This probably means that the user has an old version of the application loaded in the browser. To solve the issue the user needs to close the browser and open it again, so that the application is reloaded. IMO we should try if possible to show a similar message to the user in the browser.
Greg - is there anything we can do in such a case?
I don't think that error message is the actual issue. It sounds to me like something simply couldn't be serialized. Obviously the error message doesn't say what class couldn't be serialized, so we'd need steps to reproduce. Upon an RPC failure on the client side, I'm not sure why the browser would unload the app. Vojtech or Alexander would know that better than me. Yes, it should certainly just pop up a dialog (we do have that feature).
(In reply to Greg Sheremeta from comment #2) > I don't think that error message is the actual issue. It sounds to me like > something simply couldn't be serialized. Obviously the error message doesn't > say what class couldn't be serialized, so we'd need steps to reproduce. I didn't keep well-written notes, and do not have this anymore, but it was, more-or-less: 1. Install and setup 3.5 hosted-engine with nfs 2. Take an LVM snapshot of the hosted_storage domain on the nfs server 3. Upgrade engine to 3.6 4. Connect to the engine admin ui with a browser 5. Kill engine vm, revert it to the 3.5 lvm snapshot, start 6. Use same browser (I am pretty certain you can reproduce by running a mere engine in a VM and revert the vm to a regular snapshot, no need to play with LVM. I did this while testing hosted-engine). Solved, as the log says, by closing the browser and opening. IIRC Refresh didn't help. Obviously, the above flow is unlikely. I do not expect us to fully support it. If we do have code to pop a message, that's good enough. I was expecting it to work also for above flow :-)
(In reply to Yedidyah Bar David from comment #3) > 5. Kill engine vm, revert it to the 3.5 lvm snapshot, start > 6. Use same browser oVirt GWT UI must be "in sync" with Engine backend due to GWT RPC usage. When GWT client running in the browser sends GWT RPC (HTTP POST) request to Engine, GWT RPC servlet (Java) validates it and fails if the GWT client wasn't built for given Engine. Detailed reason: each GWT permutation (target browser/language combo) has auto-generated "strong name" that uniquely identifies it. This "strong name" is used for GWT-generated files under /usr/share/ovirt-engine/engine.ear/{webadmin,userportal}.war directory: * <strongName>.cache.js -> generated application JavaScript code * <strongName>.gwt.rpc -> GWT RPC serialization policy file > 2016-02-11 16:01:45,616 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/ovirt-engine/webadmin]] (ajp--127.0.0.1-8702-5) Exception while dispatching incoming RPC call: com.google.gwt.user.client.rpc.SerializationException: Can't find the serialization policy file. This probably means that the user has an old version of the application loaded in the browser. To solve the issue the user needs to close the browser and open it again, so that the application is reloaded. 3.5 UI for e.g. Firefox/EN has different "strong name" than 3.6 UI for e.g. Firefox/EN - GWT RPC servlet can't find proper <strongName>.gwt.rpc file and fails with above error. UI renders black screen as it's in a broken state (cannot communicate with server at all). > Solved, as the log says, by closing the browser and opening. IIRC Refresh > didn't help. Just do Ctrl-F5 to ensure the browser clears cache for the web page before requesting it from server. Alternatively, clear browser's cache via settings (but this clears cache of all opened web pages). Closing and re-opening browser should *not* be necessary. TL;DR I don't think this is really an issue -- after upgrading/downgrading Engine, users should make sure they reload UI in a way that clears existing cache to prevent loading older/newer version of UI.
(In reply to vszocs from comment #4) > TL;DR I don't think this is really an issue -- after upgrading/downgrading > Engine, users should make sure they reload UI in a way that clears existing > cache to prevent loading older/newer version of UI. This bug is about a nice pop-up, not about making the UI/backend forward/backward compatible. Is that possible? Easy? If so, I'd like to have it.
I don't think we can do the popup as requested. If you got a white blank screen it means it tried to load the javascript for a permutation that is not on the server. So there is no way for us to do anything since no javascript is loaded. Now we might be able to hook into the selector script and potentially do something from there using plain old javascript from the host page, but that would be a lot of effort for little gain.
Based on the above, Closing as WONTFIX.
UPDATE: we can do this as RFE, I see that this BZ is closed now. (In reply to Yedidyah Bar David from comment #5) > This bug is about a nice pop-up, not about making the UI/backend > forward/backward compatible. Is that possible? Easy? If so, I'd like to have > it. Sorry, I misunderstood. I agree that some user-friendly message in the browser would be nice to have. That said, if you got a blank screen, the GWT app failed to load and because of that, implementing this in a such (blank-screen-proof) way is not as easy as treating regular runtime errors that occur after the GWT app is loaded and ready. What we can do: reproduce & debug to see if we can catch this error (SerializationException) during GWT app's bootstrap sequence, if so render some message to avoid fully blank page. So I think this is doable, just not trivial. (In reply to Alexander Wels from comment #6) > I don't think we can do the popup as requested. If you got a white blank > screen it means it tried to load the javascript for a permutation that is > not on the server. So there is no way for us to do anything since no > javascript is loaded. I believe the issue here is the browser used cached permutation that isn't compatible with currently installed Engine version. Otherwise, he wouldn't be able to see the message in server.log (there wouldn't be any JS to trigger the GWT RPC request). > Now we might be able to hook into the selector script and potentially do > something from there using plain old javascript from the host page, but that > would be a lot of effort for little gain. Since GWT selector script (e.g. webadmin.nocache.js) is auto-generated, our only options are: - detect error during GWT app's bootstrap and respond - implement custom GWT linker [total overkill] I suggest to reproduce on dev. env. and see if we can catch the error in our GWT app code (e.g. BaseApplicationInit#initUncaughtExceptionHandler) and if so, add some message to page to prevent fully blank one.