Bug 828140
Summary: | Log in screen available but user is not able to log in for several minutes after installation | ||
---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Charles Crouch <ccrouch> |
Component: | Installer | Assignee: | Jay Shaughnessy <jshaughn> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Filip Brychta <fbrychta> |
Severity: | urgent | Docs Contact: | |
Priority: | urgent | ||
Version: | 4.4 | CC: | fbrychta, hbrock, hrupp, jsanda, jshaughn, lzoubek |
Target Milestone: | --- | ||
Target Release: | JON 3.1.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | 826503 | Environment: | |
Last Closed: | 2013-09-03 15:19:45 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 826503 | ||
Bug Blocks: | 782579 |
Description
Charles Crouch
2012-06-04 10:52:56 UTC
triaged into JON 3.1 per BZ triage ccrouch, asantos, loleary, mfoley. QE ..this will be in the next release candidate. As it turns out this should only affect JON and not RHQ (at least not at this time: RHQ 4.4). The reason is that JON uses a later version of jboss-web, which has the problem described above. RHQ does not. This is due to bug 773739 and bug 773737. So, QA for Master/RHQ should simply confirm that the installer still works as expected. Git cherry-pick of master commit: 8de7734a94adcec32de43ca436a12c7edecc48d9 Release-branch commit: 7207583e459c6a76145f96bccf3642d962cccfc2 This is due to the fact that the problem in bug 684450 is still unresolved, and will likely remain that way until we move to a new version of AS as the underlying RHQ server platform. When we switch contexts between the installer and portal war we start having the problem described in https://issues.jboss.org/browse/JBWEB-188. The fact that it returns a 200 response code even though the request fails is what fools the installer into thinking that the server is ready. So: - Change Startup servlet to pass back an unusual response code (288)on success - Change the installer's header.jsp to look for 288 as opposed to 200. - Change StartupServlet the polling time from 5 to 15 seconds to reduce the number of coyote exceptions. - Update the installer message to let users know that it could be several minutes in this state. Verified on 3.1.0.CR2. Main problem fixed (login screen isn't displayed before installation is finished now). 'Also in this time, when you attempt to download agent, you get 200 from server, but response-length is 0.' not fixed Bulk closing of old issues in VERIFIED state. |