Repro Steps =========== 1) start the RHQ installer. 2) closely monitor the "install in progress" page; as soon as the Click here to get started!" link appears on the page, click it. 3) when the coregui Login modal appears, immediately try to login; login will fail but without any error messages 4) wait 20 or 30 more seconds and try to login again; this time it should succeed, since the RHQ Server has now fully started Note, this does not have anything to do with files from a previous version of RHQ in the browser cache. I know this because I cleared my browser's cache before doing the above steps, and the issue still occurred.
(04:16:14 PM) mazz: the question is - "how" do we fix it. (04:16:14 PM) mazz: I think what we should end up doing is deploy the coregui webapp with a very simple little .html file (04:16:14 PM) mazz: that has metadata that turns off caching (04:16:24 PM) mazz: and our installer javascript will check the existence of that html file (04:16:46 PM) mazz: today, we check the existence of Dashboard.do (04:17:00 PM) mazz: if the javascript can get an OK/200 status from /Dashboard.do, you will see the link appear (04:17:11 PM) mazz: that's the key to when that link shows up to the user (04:28:10 PM) ips: mazz: i think if we stick w/ the http ping approach, we also need to ping an html file in coregui.war (04:28:55 PM) ips: but still, even if a GET succeeds for an html file from portal-war and one from coregui, does that def mean rhq.ear is fully deployed? (04:29:49 PM) ips: a better approach may be to have the installer call a method on a JSF managed bean that makes a call to a JBoss MBean to see if rhq.ear is started (04:30:25 PM) ips: or a call to some RHQ API - eg: isServerStarted() (04:31:27 PM) mazz: the html file would have to be in the coregui.war. (04:31:45 PM) ips: the latter would probably need to be a method on an RHQ mbean, since installer.war isn't inside rhq.ear (04:31:51 PM) mazz: but yeah, if you want to be even more specific (04:31:59 PM) mazz: have it call some server-side jsp
I wonder if this is related, or is the same problem I reported in bug 765670?
I added code to our StartupServlet - it now returns an HTTP status code of 200 when pinging /startupstatus URL. That is now what the installer uses, as opposed to Dashboard.do, to know when the installation is complete. master commit: ca7c376
verified RHQ 4.3
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE