Created attachment 491796 [details] from the message center... Steps to Reproduce: 1. Nav to Inventory->Monitoring->Tables for a resource 2. Change the time range to something other than what it is (say, 30 minutes) 3. Click Set button The update actually seems to succeed but something goes wrong resulting in the attached exception.
Not sure, this may only happen the first time you try to change from the default. I can't seem to get it to happen again. Perhaps this is the first storage of a new preference?
I wasn't able to reproduce this. I did a dbsetup to make sure I had a fresh DB and then tried updating the time range for a Resource via the Tables subtab. I didn't see any exceptions in coregui or the Server log. I then tried creating a new user, logging in as that user, and then updating the time range via the Graphs subtab (which is a JSF iframe). Again I didn't see any exceptions on client or server. Jay, any other ideas how to reproduce this?
ips, did you make sure the values cross over to the different UIs? for example, change the range in JSF and go to a GWT page and see if the value made it over there. And go the other way (change it in GWT and see its new value in a JSF page)
Ian, I have no more ideas, it's probably been fixed along the way. If we can't repro let's close/on_qa and move on.
Mazz, actually, the values appear appear to be totally independent between the JSF and GWT sides. If I change the range on the Graphs subtab (JSF), it does not change the value used on the Tables subtab (GWT), and vice verse. I'm not sure where the disconnect is. It appears as if both sides use the same preference names - JSF defines constants for the names in MeasurementPreferences (server-jar) and GWT defines constants in UserPreferenceNames (coregui). Mazz, I see that you have to metric range editor impls - UserPreferencesMeasurementRangeEditor and CustomConfigMeasurementRangeEditor. Is it possible the CustomConfigMeasurementRangeEditor is being used on the GWT side and storing the range prefs somewhere other than the traditional user preferences?
I had to play games in the code to get that to work because the JSF side stored with different delimiters then the GWT. So in the code, (I forget where), we had code that looked for either/or delimters (or something like that). In short, it had to do with the different delimiters used in the user preferences values that I had to code around. Perhaps that parsing code changed?
(02:48:03 PM) ips-lunch: mazz, i figured out what was causing the coregui and portla-war prefs to be out of sync (02:49:07 PM) ips: server-war caches the prefs for each user (SubjectPreferencesCache) and portal-war uses this cache for all prefs access (02:49:15 PM) ips: server-jar (02:49:47 PM) ips: in coregui, we load the prefs when the user logs in and then cache them (02:50:21 PM) ips: so both sides have their own cached copies which will not pick up any changes made by the other side (or via CLI, etc.) (02:50:33 PM) mazz: hmm.. but if you F5, it will reload (02:50:56 PM) ips: yes, that's the workaround for the coregui stale cache issue (02:50:58 PM) mazz: I wonder if that's how I saw it work. (02:51:12 PM) mazz: either that or my cache wasn't loaded prior to me going to the JSF page in coregui? (02:51:22 PM) mazz: my coregui cache that is (02:51:27 PM) ips: i have a fix for the portla-war stale cache issue - i just clear the server-jar cache in the updateSubject() gwt rcp impl (02:52:15 PM) ips: but fixing the coregui side won't be so easy, because of the fact that the cache is client side (02:53:09 PM) ips: we could periodically reload the prefs in coregui using a timer, but that kind of sucks (02:54:08 PM) mazz: I can hear joe now - all the way from north jersey (02:54:20 PM) mazz: ....I told you not to cache anything in the gwt app.... (02:55:08 PM) ips: or we could have a servlet in coregui that portla-war sends a request to to tell it to update its cached prefs (02:55:30 PM) mazz: nah - that's too hacky and once we get graphs in place GWT side (02:55:37 PM) mazz: (i.e. we rip out the jsf stuff completely here) (02:55:46 PM) ips: of course even portal-war will have no idea if prefs are changed via cli (02:55:50 PM) mazz: we'll be all gwt and we can do other things (02:56:10 PM) mazz: the only pref really is this range one right? (02:56:16 PM) ips: fine with me. so you think leave it as a known issue w/ the workaround being to F5? (02:56:18 PM) mazz: I mean, I can't think of any other prefs that really matter all that much (02:56:27 PM) mazz: yeah, I think that's ok (02:56:43 PM) mazz: known issue - workaround, refresh (02:56:53 PM) ips: yeah, i think so, most of the other prefs are dashboard stuff which is gwt-only now, and favorites are gwt-only too
[master 7f158ef] (http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=7f158ef) fixes prefs updates made via coregui not getting synced to portal-war. As decided above, the other half of this issue - prefs updates made via portla-war not getting synced to coregui - is going to remain a known issue with a workaround of doing a browser refresh (F5) of coregui.
Bulk closing of old issues that are in VERIFIED state.