Bug 765670 - After upgrade to 4.3, initial login fails to direct to Dashboard
After upgrade to 4.3, initial login fails to direct to Dashboard
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Installer (Show other bugs)
4.3
Unspecified Unspecified
high Severity medium (vote)
: ---
: ---
Assigned To: John Mazzitelli
Mike Foley
:
Depends On:
Blocks: 759640 jon30-sprint10/rhq43-sprint10
  Show dependency treegraph
 
Reported: 2011-12-08 22:59 EST by Jay Shaughnessy
Modified: 2012-02-07 14:30 EST (History)
6 users (show)

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


Attachments (Terms of Use)
resource not found and login failed for very few minutes (162.51 KB, image/jpeg)
2011-12-24 00:12 EST, Jeeva Kandasamy
no flags Details

  None (edit)
Description Jay Shaughnessy 2011-12-08 22:59:54 EST
Strange, and maybe this will go away but I saw this repeatedly.

1) Take an RHQ 4.1 or 4.2 DB
2) Perform an upgrade to 4.3 (I was using a snapshot at this point)
3) From the installer proceed to the login box
4) login

Here I get an error saying the backend is not available and server-side,
a log message saying /Dashboard is an invalid path.  If I login again,
just retyping the password, it works.
Comment 1 Charles Crouch 2011-12-09 13:14:19 EST
If this is reproducible its bad obviously
Comment 2 Jay Shaughnessy 2011-12-09 15:45:56 EST
Note that in the installer's header.jsp you'll find:

   var startPage = '/Dashboard.do';

   ...

   xmlRequest.open('GET', startPage, true);

I don't really know what this does but it seems related.  


Note also that ""The backend datasource is unavailable." is something of
a blanket message for any login failure other than a credentials problem.
Comment 3 Lukas Krejci 2011-12-13 09:01:04 EST
> psql -U postgres
psql> drop database rhqdev;
psql> create database rhqdev owner rhqadmin encoding 'utf8';
> git checkout RHQ_4_2_0
> cd modules/core/dbutils
> mvn install -D skipTests -Ddbsetup -Ddb=dev
> git checkout master
> mvn install -D skipTests -Ddbsetup-upgrade -Ddb=dev

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.1:run (dbsetup-worker) on project rhq-core-dbutils: Error executing ant tasks: The following error occurred while executing this line:
[ERROR] /home/metlos/Projects/java/jon/git/rhq/modules/core/dbutils/src/main/scripts/dbsetup-build.xml:291: The following error occurred while executing this line:
[ERROR] /home/metlos/Projects/java/jon/git/rhq/modules/core/dbutils/src/main/scripts/dbsetup-build.xml:315: The following error occurred while executing this line:
[ERROR] /home/metlos/Projects/java/jon/git/rhq/modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml:27: Failed to upgrade - error in spec version [2.115]. Cause: Error executing the task [org.rhq.core.db.ant.dbupgrade.SST_CreateSequence] in schema spec version [2.115]. Cause: The schema spec task [CreateSequence] has encountered an error. Cause: org.postgresql.util.PSQLException: ERROR: relation "rhq_drift_def_template_id_seq" already exists
Comment 4 Lukas Krejci 2011-12-13 09:04:35 EST
the above is w/ the master on commit 35fcafbd977ca41cb2cbff7be81787543c5224e8
Comment 5 Ian Springer 2011-12-16 11:54:12 EST
I think this is related to https://bugzilla.redhat.com/show_bug.cgi?id=759640. We need a better way of checking if the RHQ Server has fully started, rather than HTTP "pinging" /Dashboard.do.
Comment 6 John Mazzitelli 2011-12-21 18:20:00 EST
I've tried a few things (e.g. put a index.html in coregui WAR and have that pinged) but it still not working as expected. I think I'm gonna put a small servlet in the main war and have it return a 200 only when the server is really initialized. The header.jsp will then ping that servlet. This should provide what we need at low cost (that is, without writing a whole bunch of code or re-writing the installer)
Comment 7 John Mazzitelli 2011-12-22 15:59:24 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 8 Jeeva Kandasamy 2011-12-24 00:12:27 EST
Created attachment 549414 [details]
resource not found and login failed for very few minutes

Version Details:

Version: 4.3.0-SNAPSHOT
Build Number: ca7c376
GWT Version: 2.0.4
SmartGWT Version: 2.4
Browser: Firefox 3.6.24

From this build it's failed to wait until installation completion on fresh installation also. once clicked 'Install Server!' button, page immediately redirecting to 'Done! Click here to get started!' link, If we click the link it's failed to load resource (/couregui) very few minutes, after it's failed to login few minutes, hence back-end initialization process is going on at this time. Once it's working as expected after completion of all back-end initialization process.

Screen shot is attached.

Note: If I try from remote location (via VPN) get works as expected. But it's failed 100% if we try it on the same network.
Comment 10 John Mazzitelli 2012-01-03 14:16:08 EST
I cannot replicate this nor can I figure out why it would be happening. That
/startupstatus URL should only ever return a status 200 when the startup
servlet is finished and that only happens once everything is initalized.

The only thing I suspect is a browser cache issue (even though our header.jsp
and the /startupstatus returns META header tags to turn off client caching).
Comment 11 John Mazzitelli 2012-01-04 13:27:38 EST
> Note: If I try from remote location (via VPN) get works as expected. But it's
> failed 100% if we try it on the same network.

Can you explain what you mean by "on the same network"?

I tried with the browser on my local machine accessing both localhost and 192.168.x.x as my server's IP, as well as trying my VPN IP address (I had mike foley try it over the VPN address where my server was here and his browser was remote on his own box).

In other words, I cannot get this to fail.
Comment 12 Jeeva Kandasamy 2012-01-05 02:27:37 EST
(In reply to comment #11)
> > Note: If I try from remote location (via VPN) get works as expected. But it's
> > failed 100% if we try it on the same network.
> 
> Can you explain what you mean by "on the same network"?

oops, After long investigation I found that, it's happening only on SAHI proxy browsers. In automation (Sahi automation) setup, 10.65.201.148 (RHQ server) and 10.65.201.158 (client machine, browser) on the same network, hence I thought it's happening if we placed server and user on the same network, but it's wrong. it's happening only if the browser is using Sahi proxy server.
 
I tried browser with no proxy and it's working as expected.

> 
> I tried with the browser on my local machine accessing both localhost and
> 192.168.x.x as my server's IP, as well as trying my VPN IP address (I had mike
> foley try it over the VPN address where my server was here and his browser was
> remote on his own box).
> 
> In other words, I cannot get this to fail.
Comment 13 John Mazzitelli 2012-01-05 09:00:37 EST
I am therefore inclined to say there is a bug in the SAHI proxy as opposed to our code. Unless we can reproduce on a browser we support, I recommend we pass this fix.
Comment 14 Mike Foley 2012-01-16 14:40:39 EST
this is working from a product perspective.  related to UI test automation.
Comment 15 Costel C 2012-01-31 10:29:57 EST
(In reply to comment #3)
> > psql -U postgres
> psql> drop database rhqdev;
> psql> create database rhqdev owner rhqadmin encoding 'utf8';
> > git checkout RHQ_4_2_0
> > cd modules/core/dbutils
> > mvn install -D skipTests -Ddbsetup -Ddb=dev
> > git checkout master
> > mvn install -D skipTests -Ddbsetup-upgrade -Ddb=dev
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.1:run (dbsetup-worker) on
> project rhq-core-dbutils: Error executing ant tasks: The following error
> occurred while executing this line:
> [ERROR]
> /home/metlos/Projects/java/jon/git/rhq/modules/core/dbutils/src/main/scripts/dbsetup-build.xml:291:
> The following error occurred while executing this line:
> [ERROR]
> /home/metlos/Projects/java/jon/git/rhq/modules/core/dbutils/src/main/scripts/dbsetup-build.xml:315:
> The following error occurred while executing this line:
> [ERROR]
> /home/metlos/Projects/java/jon/git/rhq/modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml:27:
> Failed to upgrade - error in spec version [2.115]. Cause: Error executing the
> task [org.rhq.core.db.ant.dbupgrade.SST_CreateSequence] in schema spec version
> [2.115]. Cause: The schema spec task [CreateSequence] has encountered an error.
> Cause: org.postgresql.util.PSQLException: ERROR: relation
> "rhq_drift_def_template_id_seq" already exists


Hi Lukas,

I also tried to upgrade the database from RHQ 4.2.0 to RHQ 4.3.0-SNAPSHOT as you described above and I get the same error. How did you handle in the end the upgrade ?

Regards,
Costel
Comment 16 Jay Shaughnessy 2012-01-31 11:26:13 EST
See the upgrade note in the 4.3 release notes regarding upgrades from 4.2:

  http://rhq-project.org/display/RHQ/Release+Notes+4.3.0
Comment 17 Jay Shaughnessy 2012-01-31 11:35:21 EST
Actually, that page may not be accessible: The upgrade note:

If upgrading from RHQ 4.2 you must first make a manual change to your database.  Apply this change *only* if upgrading from RHQ 4.2, not earlier versions.  Execute the following SQL to update the schema version from 2.114 to 2.115:

update rhq_system_config 
set property_value='2.115', default_property_value='2.115' 
where property_key='DB_SCHEMA_VERSION';

After this update proceed with the upgrade normally.
Comment 18 Mike Foley 2012-02-07 14:29:26 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
Comment 19 Mike Foley 2012-02-07 14:30:11 EST
marking VERIFIED BZs to CLOSED/CURRENTRELEASE

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