Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Bad memberships and groups

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Bad memberships and groups

Chronological Thread 
  • From: Shilen Patel <>
  • To: Mirko Tasler <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Bad memberships and groups
  • Date: Tue, 24 Nov 2009 11:18:55 -0500

Hi Mirko,

To try to narrow down the problem, can you run the following SQL statements on your database? Hopefully the syntax will work with your DB. What DB are you using anyways?

select owner_id, member_id, field_id from grouper_memberships where mship_type='immediate' group by owner_id, member_id, field_id having count(*) > 1;
select owner_id, member_id, field_id from grouper_memberships where mship_type='composite' group by owner_id, member_id, field_id having count(*) > 1;
select owner_id, member_id, field_id, parent_membership from grouper_memberships where mship_type='effective' group by owner_id, member_id, field_id, parent_membership having count(*) > 1;

Let me know if you get any results back for any of the queries.


-- Shilen

On Nov 24, 2009, at 10:35 AM, Mirko Tasler wrote:

What version of Grouper are you running and how many groups do you have
with bad memberships and how many memberships do those groups have? I'm
wondering how slow this is for you and if it's unusually slow then I'm
wondering why.

Version is Grouper 1.4.2.

A more "debugging" check with FindBadMemberships.checkGroup() limited to
groups of only one of our root stems gave the following results:

* ~480 groups, each between 1 and ~5000 memberships,
* ~460 groups with bad memberships
* 30000 memberships overall

This took about 1 hour.
It takes more time per group if it has more memberships (as expected),
however some groups take noticeably more time than usual. Didn't see a
pattern though.

The findbadmemberships.gsh took 2 hours. It had errors (being unable to
remove members). Even worse, another FindBadMemberships.checkGroup()
right after found exactly the same amount of good and bad membership groups.

I tried to fix one by doing "delete from grouper_memberships where
owner_id=x" in findbadmemberships.gsh, and this led to one bad
membership group less. (Of course, test env only. I'd prefer not to use
that "solution" for prod.)

If it's slow because you're missing an index or your database isn't
tuned, then maybe fixing that will solve the issue. However, if it's
slow because the bad group has a million memberships, then we can try to
figure out what's wrong with the memberships and fix it another way.

Also we've encountered some groups whose members (always subgroups)
cannot be deleted by UI, GSH or WS,

Do your logs show an error? Are all the subjects of the member group

Yep, they're all resolvable. No, nothing in the log files (with log
level WARN). Haven't checked yet with lower log level yet (shame on me).

I'm wondering if it's hanging or if it's just adding memberships really,
really slowly or if there are just a lot of effective memberships being
created. When you add these groups as members of other groups (and
notice the hanging behavior), how many effective memberships should that
be creating? Around 10, 100, 1000, or 10000, etc?

Around 150 memberships, so I don't think it's just slow (I let it run in for 8 hours, no results, no CPU usage, so I STRG-C'd it). Also, I
can add that group as a member to other groups just fine, encountered
this problem only with one specific group as parent. What could be the
reason for this?



Archive powered by MHonArc 2.6.16.

Top of Page