Grouper Users - Open Discussion List

[Jim Fox <>]

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:

  http://staff.washington.edu/fox/grouper/

It might work for you.

Jim


On 11/10/10 9:01 PM, "Peter DiCamillo" 
<>
 wrote:

>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
>seconds.
>
>Peter
>
>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
>>halt. 
>> 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
>> Strings.
>> 
>> 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.
>> 
>> Gary
>> 
>> --On 03 October 2010 01:59 -0400 Chris Hyzer 
>> <>
>>wrote:
>> 
>>> 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
>>>a
>>> group?  Just curious, what is the workaround?  Anyways, Im sure Gary
>>>will
>>> weigh in here as well...
>>>
>>> Thanks,
>>> Chris
>>>
>>> -----Original Message-----
>>> From: 
>>> 
>>> [mailto:]
>>>  On Behalf Of Peter
>>>DiCamillo
>>> Sent: Saturday, October 02, 2010 11:14 PM
>>> To: 
>>> 
>>> 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
>>>value
>>> 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
>>>
>>> Peter
>>>
>> 
>> 
>> 
>> ----------------------
>> GW Brown, Information Systems and Computing
>> 
>