Red Hat Bugzilla – Bug 589791
Pagination through multi-page resource pages appears to share state across different RHQ users
Last modified: 2010-05-18 09:20:09 EDT
Description of problem:
It appears that if multiple users are paginating through the browse resource pages at the same time, the most recent user to click to the "next page" sets the current page for the other user. This is very bad.
Version-Release number of selected component (if applicable):
build number: 88b808d
Steps to Reproduce:
1. open a browser and login to an RHQ server as rhqadmin (or any other user). Lets call him "user1".
2. open a second browser (on the same machine or any other machine) and login to the same RHQ server as rhqadmin (or any other user). Lets call him "user2".
3. navigate both user1 and user2 to Resources > Services (or any other highly populated table like a platform's content)
at this point both users appear to be paginated to page 1
4. have user1 click to the next page
at this point user1 is on page 2
5. have user2 click to the next page
although user2 started on page 1, his click to the next page went to page 3.
The next page that user2 lands on depends on where user1 last paginated to.
Each user should paginate to the next page from where their current position, not somebody else's position.
Moreover, if user1 sorts a table column, user2 will see the same column sorted on his next page load even though user2 did not sort anything.
This would be a regression because the inventory browser (replacement for ResourceHub.do) is new and users on previous versions of the application would not see this oddity with their inventory browser. The JSF-based pagination across the entire site was designed to be specific to the user. The custom table components automatically provide isolation per user, and should make this transparent to the user of any table. Given how critical proper operation of the inventory browser is, I would think this should get high/urgent priority to determine the root cause and see if there is a systemic regression against all JSF-based tables (well over 100 of them).
FYI, I just tested this and can't reproduce. I log in as two **different** users and there is entirely no interaction between the search/filter, pagination, sorting of one user on the other session, and vice versa.
QA, can you review the reproduction steps and add any more detail that might be missing. I want to either find the root cause of this or have a reasonable explanation why you might have seen it even thought it's not an issue now.
False alarm... my apologies.
Pagination state appears to be working as designed:
Table pagination state is preserved on a per user basis regardless of how many places that user is simultaneously logged in from.
My mistake occurred when trying to log into rhq from the same browser/host as two different users (a less likely scenario). What actually happened is that I logged into rhq as user1 in browser window1 and then logged into rhq as user2 in browser window2. After I paginated in window2 as user2 and then switched to window1 and paginated, user1 was replaced with user2 and I did not realize it. So now both browser window 1 and 2 where occupied by user2 without me knowing and consequently shared the pagination state.
Moral of the story... RHQ only supports a single user login per browser session. Now I ask... Is this working as designed?
John, yes, this is working as designed. This state data is cached at the user-level, and not at the page-level. I'm thinking that this can change in the future. If we move to scroll-tables and provide reasonable sorting defaults, we probably don't need to cache sorting/pagination info at all. This is especially for any GWT-based UI we write, because state is naturally stored client-side (a.k.a, on a page-by-page basis). Regardless of which we decide is the ideal solution, we should be consistent across our various UI pages (whether they be written in JSF or GWT) so that the user doesn't have an inconsistent experience.
QA Closing as NOTABUG - can reopen later if we decide to make changes as referenced in comment #7 above.