Red Hat Bugzilla – Bug 771984
get exception when changing metric display range
Last modified: 2012-02-13 10:49:27 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.
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.
i think this might be related to bug #696214
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.
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.
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.
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.
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)
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]
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.
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.
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.
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.
verified rhq 4.3
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
marking VERIFIED BZs to CLOSED/CURRENTRELEASE