Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Hello from Duke

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Hello from Duke

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Shilen Patel <>,
  • Subject: Re: [grouper-dev] Hello from Duke
  • Date: Sat, 07 Jul 2007 08:34:26 +0100

As per blair`s request I`ll detail the API calls made by the UI, and also ask some questions.

By way of background, when browsing (apart from `All Groups`) the UI tries to only show stems which lead to groups relevant to the current context

--On 06 July 2007 12:45 -0400 Shilen Patel

Hi all,

It was great to meet everyone. I just want to mention some of the issues
we discussed in our meeting last week, so that they're documented here.

We have two main types of groups in Grouper.

1. Dynamic Groups - These are groups determined by an LDAP filter.
2. Class Roster Groups - We have 3 groups per class (instructors,
students, and TAs).
There is also a TAAdmins group that has an admin privilege to all of the
TA groups.

The issues we raised are the following.

1. Navigating through the stems viewable in the "My Memberships" section
in the UI takes about 2-3 seconds per page.
This seems slow. how many groups are average individuals a member of?

Foreach group returned

I make a Map of all the stem names (including all their parts) so that I can check if stems at the current browsing location lead to `relevant` groups.

At one point I cached the results of doing this, however, a user would then have to logout and login to see the results of changes.

2. If you are a member of the TAAdmins group, the "Manage Groups"
section takes about 10 minutes to load.

groups.addAll(member.hasStem()); //returns stems
groups.addAll(member.hasCreate()); //returns stems

Each group/stem is treated as in `1`.

For my purposes API calls such as:

boolean subjectHasDescendantAdminOrUpdatePriv(Subject subj,Stem stem)


boolean subjectHasDescendantCreateOrStemPriv(Subject subj,Stem stem)

Would ease the burden on the UI. In principle the API could have such calls, however, the privilege model is intended to be pluggable and it would not be so straightforward for an external plugin to optimise such an approach.

3. If you're not a member of the TAAdmins group and have no memberships
and no privileges, the "Manage Groups" section still takes about 30
seconds to load.
That seems very odd. I would expect the member.hasXXXX methods to return very quickly if they had nothing to return. Grouper flattens all these relationships in order to make such lookups quick.

4. Performing a group search takes about 20-30 seconds even if no
results are returned.
That is less surprising. Given the number of groups you have any search is likely to return a large number of results - however, depending on the context the UI will then try to filter* the list - which may result in no results.

*By checking if the current Subject has a specific privilege, or one of a set of privileges.

I think the API is doing a %term% type match which may not be efficient against a large database

If you do a search which cannot possibly return a result e.g. ZZZZZZZ, how long does that take?

5. Listing group members also takes a long time. If a group has X
members and you want to see the first Y members, listing the group
members causes at least X database queries and 2Y LDAP queries.
A subject may be a member of a group by several indirect paths. The Group.getMemberships methods may, therefore, return a subject several times at different points in the result list. The UI processes the whole list in order to determine a unique list of subjects.

Tom will have a better idea of what is happening at the LDAP level

6. Adding a member to the TAAdmins group takes hours.
That is an API issue due to the number of effective list entries generated

7. The xml-import takes about 3-4 days for us and requires 4 GB of
memory allocated to the Java process.
8. The only way to restrict FERPA protected data is to prevent users
from having read access to specific groups and stems that may have FERPA
protected data. It would be nice if Grouper had a way of honoring FERPA
protected data in a way such that if a user has a FERPA flag set in LDAP,
people viewing members of the group would see something like "Anonymous
User" instead of the user's name.
Does this apply to everyone or ought some privileged users have access to the data?

I`m sure we could come up with something but I would like to understand the use case better before proposing a solution.


-- Shilen

Celeste Copeland wrote:
Hello, all.

I met many of you at CAMP last week, and as per your recommendation, I
got on this mailing list. It was a pleasure to meet everyone who
participated in the Grouper discussions during CAMP. The IdM
technical group at Duke looks forward to working with you and
participating in conference calls in the near future.

- Celeste

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page