John, We appreciate your contribution and your willingness to work with us.
Rod -- Rod Simpson @rockerston rodsimpson.com On November 28, 2014 at 2:07:23 PM, John D. Ament ([email protected]) wrote: Should be good now, please let me know of any other feedback https://github.com/johnament/incubator-usergrid/commit/bbdeafa4858dd386303beddf581092a3d4983692 On Fri Nov 28 2014 at 3:50:32 PM John D. Ament <[email protected]> wrote: > Yes, making it configurable is what I was starting on. I'll switch the > param to the one you listed, and I have the code set to leave it to 10 if > not set. > > In the long run, we're probably going to use the portal as an interim > solution until we can better integrate to the REST API for things like > message counts. > > John > > > On Fri Nov 28 2014 at 3:33:33 PM Ed Anuff <[email protected]> wrote: > >> 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 >> > > > >> > > >> > >> >
