It's not ideal, but it is actually regularly used in production the way it works now. Most of the time, the superuser account is not used via the web UI, it's used via the REST API or the command line client. If we want to up the limit from 10 to some other larger number for convenience, that's probably ok, but it will really slow down the login depending on how many orgs people have. I'd suggest this be a configuration file option rather than a hardcoded thing so that we don't break behavior for production users (usergrid.sysadmin.login.fetch_orgs=10). I'm of the opinion we should be refactoring of the login so that it doesn't return any orgs via the login and those are all retrieved by a subsequent call that can iterate through the orgs.
Ed On Fri, Nov 28, 2014 at 12:01 PM, John D. Ament <[email protected]> wrote: > I would have to question whether the way it behaves now is feasible, for > anyone. How many of your customers are actually logging in using the > superuser account? > > If they really are going in and looking at 100k orgs, how do they deal with > this problem? > > On Fri Nov 28 2014 at 2:34:13 PM Ed Anuff <[email protected]> wrote: > > > Making this change is not advised. When a management user logs in, all > the > > organizations they are a member of and all the applications associated > with > > those organizations are loaded. There are companies running Usergrid in > > production as a multi-tenant BaaS with upwards of 100,000 organizations. > > The superuser is a member of every organization, so when they log in, it > > takes a very long time if all the orgs are loaded and basically times > out. > > That's why the limit of 10 was put in as a kludge. The proper fix would > > have been to make those methods paginate, but if we just up the limit > from > > 10 to 1000 or whatever, it will be a breaking change for production > > systems. > > > > Ed > > > > > > On Fri, Nov 28, 2014 at 10:44 AM, John D. Ament <[email protected]> > > wrote: > > > > > On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <[email protected]> > > wrote: > > > > > > > Currently, the max result set we allow in UG is 1k. > > > > > > > > > > I pulled 10k from this line: > > > > > > > > > https://github.com/apache/incubator-usergrid/blob/ > > master/stack/services/src/main/java/org/apache/usergrid/ > > management/cassandra/ManagementServiceImpl.java#L697 > > > > > > If you want, I can reduce both of them to 1k. > > > > > > John > > > > > > > > > > > > > > Rod Simpson > > > > > > > > On Fri, Nov 28, 2014 at 6:47 AM, John D. Ament < > [email protected]> > > > > wrote: > > > > > > > > > All, > > > > > I put in a local fix for USERGRID-258 > > > > > <https://issues.apache.org/jira/browse/USERGRID-258>. It looks > like > > > the > > > > > query was hard coded to only return 10, and further more the > default > > > > logic > > > > > in the query APIs limits to 10 by default. > > > > > I switched it to 10000 which should be sufficient, however i'm > > > wondering > > > > if > > > > > a broader change may be required at some point. The scope of my > > change > > > > was > > > > > in ManagementServiceImpl > > > > > organizations = buildOrgBiMap( getOrganizations( null, > > > 10000 > > > > ) > > > > > ); > > > > > Is there any issue with this change for now? I noticed in the UI > it > > > was > > > > > rendering fine when I added many organizations. > > > > > I also took the liberty of upgrading apache parent to the latest. > > > > > John > > > > > >
