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: Wed, 25 Nov 2009 11:06:51 -0500

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




Archive powered by MHonArc 2.6.16.

Top of Page