Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper 1.6.1 UI membership list sorting

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper 1.6.1 UI membership list sorting


Chronological Thread 
  • From: Peter DiCamillo <>
  • To: "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 23:01:42 -0500
  • Authentication-results: cox.net; none

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





Archive powered by MHonArc 2.6.16.

Top of Page