Bug 771984 - get exception when changing metric display range
get exception when changing metric display range
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
Unspecified Unspecified
high Severity high (vote)
: ---
: RHQ 4.3.0
Assigned To: John Mazzitelli
Mike Foley
Depends On:
Blocks: jon30-sprint10/rhq43-sprint10 790078
  Show dependency treegraph
Reported: 2012-01-05 10:27 EST by John Mazzitelli
Modified: 2012-02-13 10:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 790078 (view as bug list)
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
error.log (82.28 KB, text/x-log)
2012-01-05 10:27 EST, John Mazzitelli
no flags Details

  None (edit)
Description John Mazzitelli 2012-01-05 10:27:02 EST
Created attachment 550942 [details]

Go to Measurement Graph view - try to change the date range. Get exception on server and red error in UI that says "Cannot store preferences"

See the attached error.log - very long set of exceptions.
Comment 1 John Mazzitelli 2012-01-05 10:31:30 EST
this happens when you change the date range anywhere the date range component is - it isn't localized to the Measurement Graph subtab. The Table subtab and the Summary>Timeline subtab also shows this bug.
Comment 2 John Mazzitelli 2012-01-05 14:33:07 EST
i think this might be related to bug #696214
Comment 3 John Mazzitelli 2012-01-05 16:18:19 EST
looks like three calls immediate get sent to the server (SubjectGWTServiceImpl.updateSubject()). Two of them fail. I suspect it some kind of concurrency thing - we are making three calls to update the DB and two of them fail.

Probably has something to do with the auto-update functionality in the UserPreferences stuff in the GWT app.
Comment 4 John Mazzitelli 2012-01-05 16:24:15 EST
here's something that is weird. I start the gwt dev mode, connect to the app through it, change the date range, and it works fine. I then switch to the non-dev mode URL, change the date range again, and it WORKS. I can't get it to fail.

It must be that once the initial save works fully, whatever condition existed that caused the bug goes away.
Comment 5 John Mazzitelli 2012-01-06 12:42:54 EST
More replication procedures.

It appears this ONLY happens when you first log onto a new server that started with an empty DB. I do a dbsetup, start the server, log in, import a platform, set my date range - boom - the bug happens.

BUT! If I kill my browser, restart and re-login - the problem doesn't happen. Also if I restart the server, relogin, it doesn't happen.
Comment 6 John Mazzitelli 2012-01-06 12:48:59 EST
more replication procedures:

I can see this by creating a new user, log out and log in as the new user, and set the date range. poof - bug. But then log out, log back in as that new user, and now it works.

So it appears only the first time you try it, it fails for that login. Log out then back in again, the problem no longer happens.
Comment 7 John Mazzitelli 2012-01-06 15:20:32 EST
this problem is very much like bug #698591 - same thing, only with this bug, its when changing the date range (which causes up to 3 user prefs to be changed concurrently via async callbacks)
Comment 8 John Mazzitelli 2012-01-09 11:14:10 EST
random notes: I put a breakpoint in the updateSubject SLSB method and I examine the subjectToModify with the currentSubject and I see the subjectToModify is missing user preference properties .last.url and monitor.visibility.indicator.views.10001.Default. Stored in the DB (that the GWT request didn't know about) is:

.last.url=PropertySimple[id=14244, name=.last.url, value=http://localhost:7080/rhq/resource/monitor/graphs-plain.xhtml?id=10001, override=null]

monitor.visibility.indicator.views.10001.Default=PropertySimple[id=14245, name=monitor.visibility.indicator.views.10001.Default, value=10001,10007|10001,10002|10001,10009|10001,10012|10001,10003, override=null]

I also noticed the subjectToModify had this:

.recent.resources=PropertySimple[id=0, name=.recent.resources, value=10001, override=null]

and the currentSubject has this (notice the non-zero ID)

.recent.resources=PropertySimple[id=14300, name=.recent.resources, value=10001, override=null]
Comment 9 John Mazzitelli 2012-01-09 11:33:23 EST
if I were to directly log into the Monitoring>Tables subtab (that is, do NOT go into a struts/jsf page like the graphs page) I don't see those two extra ones (which, IIRC, are only created by the struts/jsf pages - last.url and the graph views).

However, the .recent.resources one is still wrong - its getting 0 passed in but its already persisted with a valid ID in the DB.
Comment 10 John Mazzitelli 2012-01-09 11:40:35 EST
ok, confirmed the problem is the ID=0 for the .recent.resources.

It looks as though the GWT user prefs are cached on this page and somewhere on another page, we stored .recent.resources but wasn't put into our cache.  So, once recent.resources is persisted, it got a new ID, but we never stored that new ID in our cache.
Comment 11 John Mazzitelli 2012-01-09 15:28:09 EST
git master commit ac23911

it appears that trying to concurrently update a subject's user preferences fails when one of the updates involves inserting a new property. The problem appears from the GWT client, so at the GWT servlet layer, we will now ensure that no two GWT requests can concurrently update a subject.

to replicate:

1) make sure you have at least one platform imported in inventory
2) as rhqadmin, create a new user "bob" and give him manage inventory permissions
3) log out and then log in as user "bob"
4) navigate to a platform
5) go to Monitoring>Table subtab
6) try to change the date range

you should no longer see global exception messages.
Comment 12 Mike Foley 2012-01-16 13:07:45 EST
verified rhq 4.3
Comment 13 Mike Foley 2012-02-07 14:30:41 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
Comment 14 Mike Foley 2012-02-07 14:30:45 EST

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