Bug 759640 - installer presents user with "Click here to get started!" link to coregui before the RHQ Server has fully started
installer presents user with "Click here to get started!" link to coregui bef...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Installer (Show other bugs)
4.2
Unspecified Unspecified
medium Severity medium (vote)
: ---
: ---
Assigned To: Jeeva Kandasamy
Mike Foley
:
Depends On: 765670
Blocks: jon30-sprint10/rhq43-sprint10
  Show dependency treegraph
 
Reported: 2011-12-02 16:53 EST by Ian Springer
Modified: 2013-08-05 20:42 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-07 14:27:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2011-12-02 16:53:29 EST
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.
Comment 1 Ian Springer 2011-12-02 16:54:40 EST
(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
Comment 3 Jay Shaughnessy 2011-12-09 15:46:06 EST
I wonder if this is related, or is the same problem I reported
in bug 765670?
Comment 4 John Mazzitelli 2011-12-22 15:58:57 EST
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
Comment 5 Mike Foley 2012-01-16 14:41:25 EST
verified RHQ 4.3
Comment 6 Mike Foley 2012-02-07 14:27:26 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

Note You need to log in before you can comment on or make changes to this bug.