You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by "John D. Ament" <jo...@apache.org> on 2014/11/28 14:46:55 UTC
USERGRID-258 - max 10 organizations
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
Re: USERGRID-258 - max 10 organizations
Posted by "John D. Ament" <jo...@apache.org>.
Rod,
Anything to help you guys grow the community more.
On Fri, Nov 28, 2014 at 5:22 PM, Rod Simpson <ro...@rodsimpson.com> 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 (johndament@apache.org)
> 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 <jo...@apache.org>
> 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 <ed...@anuff.com> 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 <jo...@apache.org>
> >> 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 <ed...@anuff.com> 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 <
> >> johndament@apache.org>
> >> > > wrote:
> >> > >
> >> > > > On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <rod@rodsimpson.com
> >
> >> > > 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 <
> >> > johndament@apache.org>
> >> > > > > 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
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: USERGRID-258 - max 10 organizations
Posted by Rod Simpson <ro...@rodsimpson.com>.
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 (johndament@apache.org) 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 <jo...@apache.org>
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 <ed...@anuff.com> 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 <jo...@apache.org>
>> 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 <ed...@anuff.com> 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 <
>> johndament@apache.org>
>> > > wrote:
>> > >
>> > > > On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <ro...@rodsimpson.com>
>> > > 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 <
>> > johndament@apache.org>
>> > > > > 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
>> > > >
>> > >
>> >
>>
>
Re: USERGRID-258 - max 10 organizations
Posted by "John D. Ament" <jo...@apache.org>.
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 <jo...@apache.org>
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 <ed...@anuff.com> 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 <jo...@apache.org>
>> 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 <ed...@anuff.com> 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 <
>> johndament@apache.org>
>> > > wrote:
>> > >
>> > > > On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <ro...@rodsimpson.com>
>> > > 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 <
>> > johndament@apache.org>
>> > > > > 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
>> > > >
>> > >
>> >
>>
>
Re: USERGRID-258 - max 10 organizations
Posted by "John D. Ament" <jo...@apache.org>.
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 <ed...@anuff.com> 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 <jo...@apache.org>
> 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 <ed...@anuff.com> 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 <johndament@apache.org
> >
> > > wrote:
> > >
> > > > On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <ro...@rodsimpson.com>
> > > 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 <
> > johndament@apache.org>
> > > > > 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
> > > >
> > >
> >
>
Re: USERGRID-258 - max 10 organizations
Posted by Ed Anuff <ed...@anuff.com>.
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 <jo...@apache.org>
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 <ed...@anuff.com> 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 <jo...@apache.org>
> > wrote:
> >
> > > On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <ro...@rodsimpson.com>
> > 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 <
> johndament@apache.org>
> > > > 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
> > >
> >
>
Re: USERGRID-258 - max 10 organizations
Posted by "John D. Ament" <jo...@apache.org>.
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 <ed...@anuff.com> 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 <jo...@apache.org>
> wrote:
>
> > On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <ro...@rodsimpson.com>
> 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 <jo...@apache.org>
> > > 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
> >
>
Re: USERGRID-258 - max 10 organizations
Posted by Ed Anuff <ed...@anuff.com>.
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 <jo...@apache.org>
wrote:
> On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <ro...@rodsimpson.com> 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 <jo...@apache.org>
> > 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
>
Re: USERGRID-258 - max 10 organizations
Posted by "John D. Ament" <jo...@apache.org>.
On Fri Nov 28 2014 at 12:08:37 PM Rod Simpson <ro...@rodsimpson.com> 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 <jo...@apache.org>
> 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
Re: USERGRID-258 - max 10 organizations
Posted by Rod Simpson <ro...@rodsimpson.com>.
Currently, the max result set we allow in UG is 1k.
Rod Simpson
On Fri, Nov 28, 2014 at 6:47 AM, John D. Ament <jo...@apache.org>
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