Grouper Users - Open Discussion List

[Shilen Patel <>]

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.

Thanks!

-- 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
> > resolvable?
>
> 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
> gsh.sh 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?
>
> Thanks,
>
> Mirko