[OPENAM-2200] json/sessions/?_queryID=all only returning 120 sessions Created: 19/Feb/13 Updated: 20/Nov/16 Resolved: 29/Feb/16
|Affects Version/s:||11.0.0, 12.0.1, 12.0.2, 13.0.0|
|Reporter:||Sam Drew||Assignee:||Robert Wapshott|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Sprint:||Sprint 22, Sprint 23, Sprint 24, Sprint 25, Sprint 26, Sprint 27|
|Support Ticket IDs:|
When calling json/sessions/?_queryID=all with lots of sessions already created, only the 120 of them are returned.
This is because each Server responding to the Session Request uses its configured limit to determine how many SessionInfo's are returned.
Importantly the solution must be able to scale to whatever size we plan to deploy OpenAM to. This could mean many thousands or millions of active users and thereforeSessions.
The current proposal would be to improve the type of information that can be specifiedin the SessionRequest query. This would allow the caller to define how much informationto return in the query.
This would allow us to make use of the ForgeRock REST functionality for paging to thenallow the SessionResource to control which page of SessionInfo should be returned from which server.
This is a stories worth of work rather than a simple bug fix.
|Comment by Sam Drew [ 19/Feb/13 ]|
This is 120 results per server.
|Comment by Peter Major [X] (Inactive) [ 20/Feb/13 ]|
Most likely related to the Global Session service search result limit. Should this resource really return all the sessions?
|Comment by Sam Drew [ 20/Feb/13 ]|
My understanding is that the intention is for it to eventually be paginated, so you can retrieve a page containing a given number of sessions, and then you can request the following pages one at a time.
|Comment by Bernhard Thalmayr [ 11/Dec/15 ]|
The linked issue
|Comment by Nathalie Hoet [ 08/Jan/16 ]|
Would/should this solution also allow to return sessions according to criteria, such as the username ?
|Comment by Peter Major [X] (Inactive) [ 29/Feb/16 ]|
This is not something we wish to implement. The better solution for this would be