On larger servers, the /subjects and /experiments queries take several minutes to return. When executed multiple times, it ties up a database connection for a long time. If its run several times, it can lock up a server by tying up all of its db connections.

Additionally, returning millions of rows at a time is generally unusable.

To prevent this we will add paging to these rest calls. And we will add a site configuration property to determine if the calls should default to paging or not. The default will be ‘not’, to stay consistent with prior behavior. But, for larger servers, they will be able to change the default to paging ‘on’ to prevent accidental DoS.

Additionally, the corresponding project-level listings (/data/projects/x/subjects & /data/projects/x/experiments) will be modified to support paging, though their default behavior will not be modifiable, as portions of the app are dependent on them returning all rows by default. We may need to revisit this to support single projects with millions of rows, but that will require refactoring of several UI components.