Rod, Anything to help you guys grow the community more.
On Fri, Nov 28, 2014 at 5:22 PM, Rod Simpson <[email protected]> wrote: > 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 > >> > > > > >> > > > >> > > >> > > >
