Subject: Grouper Users - Open Discussion List
Re: [grouper-users] Grouper 1.6.1 UI membership list sorting
- From: Jim Fox <>
- To: Peter DiCamillo <>, "GW Brown, Information Systems and Computing" <>, Chris Hyzer <>
- Cc: <>
- Subject: Re: [grouper-users] Grouper 1.6.1 UI membership list sorting
- Date: Wed, 10 Nov 2010 20:28:46 -0700
I don't use this anymore, because I've found it better to keep the
subjects in the Grouper DB. We did for a while use this LDAP subject
source that keeps connections open:
It might work for you.
On 11/10/10 9:01 PM, "Peter DiCamillo"
>I've been looking into a local workaround for this, and I found that
>sorting itself is not too slow, but it's very time-consuming to lookup
>in our subject source, LDAP, the name for each subject. This makes
>option 1 slow for just a modest number of members.
>The LDAP log shows that Grouper is doing a new bind to LDAP for each
>name lookup. If I have a collection of subjects, is there a way in
>Grouper to lookup the names for all of them using a single LDAP bind
>session? I did a test using a standalone script with LDAP, and found
>that doing 1500 lookups using a new bind for each one took 36 seconds,
>but using a single bind session for all of the lookups took only 9
>GW Brown, Information Systems and Computing wrote:
>> The problem is that the API is now doing the paging - but it has no
>> means to sort the data because, as Chris says, we don't store subject
>> attributes. API paging was added because even without sorting,
>> processing very large memberships would bring the UI to a grinding
>> So, unfortunately the comparator.sort.limit has become redundant.
>> Going forward I think there are a coupe of options.
>> 1) The UI checks how many results there will be and if under
>> comparator.sort.limit sets this as the pagesize for the API.
>> 2) The API stores a sort String for subjects so it can add an order by
>> clause to its query. Some mechanism would be needed to refresh sort
>> I can have a look at option 1, but we have talked about option 2 before
>> so I'll wait and see what the consensus is. Either way it is likely to
>> be 2.0 before we resolve it.
>> --On 03 October 2010 01:59 -0400 Chris Hyzer
>>> I can reproduce that. The problem is that subject data is stored
>>> externally to Grouper (in sources), so if there are 50000 subjects in a
>>> group, that is 50000 subject lookups (assuming none in cache), which
>>> doesn't scale. Granted if you had 356 with 250 on a page, that should
>>> sort. :) What use case do you have? Trying to see if someone is in
>>> group? Just curious, what is the workaround? Anyways, Im sure Gary
>>> weigh in here as well...
>>> -----Original Message-----
>>> On Behalf Of Peter
>>> Sent: Saturday, October 02, 2010 11:14 PM
>>> Subject: [grouper-users] Grouper 1.6.1 UI membership list sorting
>>> I'm having a problem where membership lists I view in the full Grouper
>>> UI are not sorted as I would expect. When the size of the membership
>>> list does not exceed the page size the list is sorted. But when more
>>> than one page is needed, the list on each page is not sorted. The
>>> of comparator.sort.limit in media.properties is 50000, larger than the
>>> size of any of our groups, because even if it's slow, we always want
>>> sorted lists.
>>> For example, I viewed a list with 2 direct members and 356 indirect
>>> members. When I viewed the indirect members or all members with a page
>>> size of 500 the list was sorted. But with a page size of 250 the lists
>>> on the pages were not sorted.
>>> I didn't install Grouper 1.3, but we may have had a local fix for this.
>>> But in any case, it appears that since 1.3 the code that for handling
>>> pages and sorting has changed
>> GW Brown, Information Systems and Computing
- Re: [grouper-users] Grouper 1.6.1 UI membership list sorting, Peter DiCamillo, 11/10/2010
- Re: [grouper-users] Grouper 1.6.1 UI membership list sorting, Jim Fox, 11/10/2010
Archive powered by MHonArc 2.6.16.