Bug 790078

+++ This bug was initially created as a clone of Bug #771984 +++

Created attachment 550942 [details]
error.log

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.

--- Additional comment from mazz on 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.

--- Additional comment from mazz on 2012-01-05 14:33:07 EST ---

i think this might be related to bug #696214

--- Additional comment from mazz on 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.

--- Additional comment from mazz on 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.

--- Additional comment from mazz on 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.

--- Additional comment from mazz on 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.

--- Additional comment from mazz on 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)

--- Additional comment from mazz on 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]

--- Additional comment from mazz on 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.

--- Additional comment from mazz on 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.

--- Additional comment from mazz on 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.

--- Additional comment from mfoley on 2012-01-16 13:07:45 EST ---

verified rhq 4.3

--- Additional comment from mfoley on 2012-02-07 14:30:41 EST ---

changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

--- Additional comment from mfoley on 2012-02-07 14:30:45 EST ---

marking VERIFIED BZs to CLOSED/CURRENTRELEASE