Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Log in screen available but user is not able to log in for several minutes after installation|
|Product:||[Other] RHQ Project||Reporter:||Filip Brychta <fbrychta>|
|Component:||Installer||Assignee:||Jay Shaughnessy <jshaughn>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Version:||4.4||CC:||hrupp, jshaughn, lzoubek|
|Target Release:||RHQ 4.5.0|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||828140 (view as bug list)||Environment:|
|Last Closed:||2013-08-31 05:55:19 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Filip Brychta 2012-05-30 07:25:03 EDT
Description of problem: Log in screen is available before the installation process is complete. Attempts to log in end with no result, no error message is displayed. This lasted for several minutes until log in was successful. Version-Release number of selected component (if applicable): Version: 3.1.0.CR1 Build Number: 4bc4270:1b85993 How reproducible: Always Steps to Reproduce: 1.follow JON installation process (include several plugins), choose overwrite data (if there is some previous installation) 2.try to log in as soon as log in page is avaiable Actual results: user stays on log in page with no result, no error message is shown following error is thrown to server log: 2012-05-30 12:31:12,336 ERROR [org.apache.catalina.connector.CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:507) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:449) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:239) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:679) Expected results: user is logged in Additional info: I could see that installation was still in progress (messages like 2012-05-30 12:31:20,693 INFO [org.rhq.enterprise.server.resource.metadata.ResourceMetadataManagerBean] Persisting new ResourceType [JBossAS7:Param(id=0)]... ) in server log. So the problem is that a log in screen is available before installation process is actually finished.
Comment 1 Libor Zoubek 2012-06-01 13:07:56 EDT
Also in this time, when you attempt to download agent, you get 200 from server, but response-length is 0.
Comment 2 Jay Shaughnessy 2012-06-01 17:28:47 EDT
This is due to the problem described in bug 684459. The problem is that when we switch from the installer to portal war and change the root context we hit that problem. That causes a 200 to be returned (why why why?) even though the server hits an exception. Which makes the installer think that startupServlet is responding.
Comment 3 Jay Shaughnessy 2012-06-02 17:24:51 EDT
Comment 4 Jay Shaughnessy 2012-06-02 17:25:40 EDT
master commit 8de7734a94adcec32de43ca436a12c7edecc48d9 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.
Comment 5 Jay Shaughnessy 2012-06-04 11:57:54 EDT
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 773737. So, QA for Master/RHQ should simply confirm that the installer still works as expected.
Comment 6 Filip Brychta 2013-08-26 05:17:05 EDT
Verified on Version: 4.9.0-SNAPSHOT Build Number: d428376