Grouper Users - Open Discussion List

[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 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