Grouper Users - Open Discussion List

[Shilen Patel <>]

> > 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;
>
> Returns one row after 609ms.


Ok that one row indicates one duplicate membership.  It's possible  
that this is causing some of the problems for you.  But there could be  
other problems as well.  Also, as Chris mentioned, this type of issue  
is not possible with Grouper 1.5.0 because of the restructuring of  
memberships and new database constraints.  Bad membership finder in  
1.4 doesn't correct this particular issue.

Perform the following query using the owner_id, member_id, and  
field_id you got back:

select * from grouper_memberships where owner_id=? and member_id=? and  
field_id=? and mship_type='immediate';

You will get two or more rows back but there should only be one.  Try  
deleting all but one row.  If you get foreign key constraint  
violations on parent_membership, you'll have to delete those child  
rows as well.  If deleting those child rows also causes foreign key  
constraint violations on parent_membership, delete those child rows as  
well... and so forth.

Afterwards, try running bad membership finder on just one of the  
groups that was giving you an issue before.  If it reports errors, try  
running the GSH script and re-run bad membership finder.  If it's  
still not corrected, I can try looking at the rows you have in your  
grouper_memberships table to see what's going on.

Thanks!

-- Shilen



On Nov 25, 2009, at 9:50 AM, Mirko Tasler wrote:

> > 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?
>
> We're using PostgreSQL 8.2.
>
> > 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;
>
> Returns one row after 609ms.
>
> > 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;
>
> Returns nothing after 22ms.
>
> > 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;
>
> Returns nothing after 5653ms.
>
> > > 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).
>
> > Shilen can respond to the other parts, but Im concerned about lack of
> > logging.  You are saying that when your log level is set to warn, and
> > you try to remove a member of a group via the UI and get an error,
> > you don't see anything in the logs?  What error do you see on the
> > screen?
>
> There's no error:
>
> > > I let it run in gsh.sh for 8 hours, no results, no CPU usage, so I
> > > STRG-C'd it).
>
> Basically, executing parentGroup.addMember(childGroup) in gsh never
> returned. Had this effect also when deleting from some other group,
>
> Now, I let it run even longer and... got an OutOfMemoryError. Still,  
> the
> last message in the log is the gsh startup message.
>
> The parent group in this case also has lots of privileges everywhere,
> could this be a problem?
>
> > grouperLoaderGroupsLike
> > which is a SQL pattern of group names managed by the loader.  If a
> > group in your registry matches that string, but has no memberships in
> > the loader, and is not in the optional grouperLoaderGroupQuery, then
> > it will be removed.  It is a little more complicated if the group is
> > an include/exclude group.
>
> Okay, fixed that one - thanks a lot!
> Apparently, Grouper Loader does not remove empty Stems too, even if it
> created them itself?
>
> > Also, is this a production emergency where things aren't working, or
> > are you limping along?
>
> If need be, we're happy to limp even further. ;)
> We cannot update to 1.5 prior to May 2010 due to team resources.
> Luckily, none of the problems is a real showstopper.
>
> Thanks again!
>
> Mirko