How to reproduce this problem:
1. build oVirt, start JBoss, open WebAdmin in browser
2. stop JBoss, rebuild oVirt again, keep "old" WebAdmin opened in the browser
3. since JBoss was stopped, "old" WebAdmin will report this error message:
"Error: A Request to the Server failed with the following Status Code: 500"
4. start JBoss again, and watch the JBoss console, following exceptions appear:

ERROR [[/webadmin]] Exception while dispatching incoming RPC call
com.google.gwt.user.client.rpc.SerializationException: Could not find
ClientOracle data for permutation 9DA981D034209E3FF4BC2B631FDB3DA8

This is not a bug of WebAdmin. The problem is that "old" WebAdmin keeps trying
to reach JBoss backend, while WebAdmin server-side files were recompiled and
redeployed in the meantime. Simply close the "old" WebAdmin in your browser.

Explanation:

Each time you build oVirt, WebAdmin code is compiled into JavaScript by GWT
compiler. WebAdmin JavaScript is divided into several smaller permutations,
typically one per each supported browser. Each permutation has a strong name,
e.g. "9DA981D034209E3FF4BC2B631FDB3DA8".

WebAdmin server-side files are put to
/path-to-jboss/server/default/deploy/engine.ear/webadmin.war/webadmin, for
example: 9DA981D034209E3FF4BC2B631FDB3DA8.gwt.rpc

Since permutation strong name changes between GWT compilations, "old" WebAdmin
tries to reference server-side files that no longer exist.

Solution:

Just close the "old" WebAdmin in your browser after rebuilding/redeploying
oVirt, and open new browser tab (or window) requesting WebAdmin again.

Moving this to MODIFIED, rvaknin - please verify if the above solution works
for you.

Works for me, I needed to close the browser and clear its cache , tested on devel env, last commit's hash: da5f1e1391028f956d6f7040a1d6a1501f90d44c

*** Bug 783985 has been marked as a duplicate of this bug. ***

I still hit this issue; cache doesn't seem to be cleared. 


2012-02-05 06:51:29,622 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/webadmin]] (http--0.0.0.0-8080-2) Exception while dispatching incoming RPC call: com.google.gwt.user.client.rpc.SerializationException: C
ould not find ClientOracle data for permutation 343720C180478ED34BEDA7158D17C6DC
        at com.google.gwt.rpc.server.RpcServlet.findClientOracleData(RpcServlet.java:279) [gwt-servlet-2.3.0.jar:]
        at com.google.gwt.rpc.server.RpcServlet.getClientOracle(RpcServlet.java:115) [gwt-servlet-2.3.0.jar:]
        at com.google.gwt.rpc.server.RpcServlet.processPost(RpcServlet.java:194) [gwt-servlet-2.3.0.jar:]
        at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) [gwt-servlet-2.3.0.jar:]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.3.Final.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.3.Final.jar:]
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.3.Final.jar:]
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.3.Final.jar:]
        at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.Beta1b.jar:]
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.3.Final.jar:]
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.3.Final.jar:]
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.3.Final.jar:]
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.3.Final.jar:]
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.3.Final.jar:]
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.3.Final.jar:]
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.3.Final.jar:]
        at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]

git hash: 9dacd053d6d011b374b8fc83b88f8e7de368aabf

Hi, can you post exact steps to reproduce the issue?

The stack trace just says that server-side WebAdmin files (permutations) cannot be found by RPC servlet. This typically means that new WebAdmin version has been deployed on JBoss.

Try closing WebAdmin in your browser, then clear your browser cache, restart JBoss and request WebAdmin in browser again.

(In reply to comment #5)
> Hi, can you post exact steps to reproduce the issue?
> 
> The stack trace just says that server-side WebAdmin files (permutations) cannot
> be found by RPC servlet. This typically means that new WebAdmin version has
> been deployed on JBoss.
> 
> Try closing WebAdmin in your browser, then clear your browser cache, restart
> JBoss and request WebAdmin in browser again.

- logged in to web-admin 
- stop service 
- recompile 
- start service again 
- try to relogin (during that time, browser is opened)

I see. You should close WebAdmin tab in your browser before stopping JBoss service. WebAdmin periodically queries the backend when you are logged in. When you start the service again, "old" WebAdmin will try to query backend again.

WebAdmin and backend need to be in sync (that's what the RPC exception is about). When "old" WebAdmin queries the backend, "Could not find ClientOracle data" exceptions will occur since client and server are not in sync. It's not a bug of the application itself, it just means you should request WebAdmin in new tab each time you recompile/upgrade oVirt.

shouldn't webadmin detect it is out of sync and go back to the login page for user to re-login?

Well, what we can do is implement some detection logic (that runs periodically?) that checks if client and server are in sync, and if not, reload the whole web page to restart the application. But if the user does "yum upgrade ovirt", he knows that the backend will change, and he knows he needs to restart WebAdmin in his browser. It should be as simple as pressing F5 (reload page).

One way of dealing with out-of-sync-detection by application, is catching RPC exceptions and for certain type of exception, we'd know that its due to out-of-sync and we can refresh the page. But this approach just automates what users can do anyway since they know when the backend has changed.

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.