Grouper Users - Open Discussion List

["Waldbieser, Carl" <>]

Dave,

We noticed this issue in Grouper 2.2 and had a shell script repeatedly run 
the Bad Membership Finder and check the output until it didn't find any more 
errors.

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College

----- Original Message -----
From: "Dave Churchley" 
<>
To: "Shilen Patel" 
<>
Cc: "grouper-users" 
<>
Sent: Friday, October 20, 2017 10:12:32 AM
Subject: RE: [grouper-users] Composite group problems

Yes, that makes sense. I've now scheduled the Bad Membership Finder Utility 
to run each morning, just after the Grouper loader groups are populated.

One more question, if you don't mind, do you know why it took four goes to 
fix all the bad memberships this morning? Each time I ran it, it fixed the 
majority that it had found, but not all of them.

Thanks
Dave

From: 

 
[mailto:]
 On Behalf Of Shilen Patel
Sent: 20 October 2017 11:46
To: Dave Churchley 
<>
Cc: 

Subject: Re: [grouper-users] Composite group problems

OK cool.  The scenario you described is a similar situation where you 
probably have two threads running at the same time that deleted and added the 
user from/to the groups under Group B.  The thread that deleted the user from 
the group under B would have thought the user wasn't an effective member of B 
anymore and would have deleted the user from A.  Meanwhile the thread that 
added the user to the group under B would have seen that the user is already 
in A (since the other transaction may not have committed yet) and therefore 
wouldn't have done anything else.  Does that at least explain the issue?  We 
created the bad membership daemon in 2.3 because of this issue but we may 
need to handle it better.

Thanks!

- Shilen



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: Dave Churchley 
<<mailto:>>
Date: 10/20/17 1:28 AM (GMT-08:00)
To: Shilen Patel 
<<mailto:>>
Cc: 
<mailto:>
Subject: RE: [grouper-users] Composite group problems

Thanks again Shilen

The Bad Membership Finder Utility cleaned up 118 bad memberships this 
morning. (I had to run it four times though until it found no membership 
errors.) I'm sure this utility will be useful to us!

I don't know if you're able to explain why the composite group memberships go 
wrong as in the example below?

Thanks
Dave

From: 
<mailto:>
 
[mailto:]
 On Behalf Of Dave Churchley
Sent: 19 October 2017 20:56
To: Shilen Patel 
<<mailto:>>
Cc: 
<mailto:>
Subject: Re: [grouper-users] Composite group problems

Thanks Shilen, I'll take a look at that in the morning.

For at least one of the problem groups, however, this is definitely not the 
issue. Group A is made up of Group B complement Group C. Person X was in B 
and not C and so he rightly appeared in A. Two days ago he dropped out of A 
but he remained in B and not in C. Those groups' memberships hadn't changed. 
We did notice that Group B was built from several Grouper loader groups and 
Person X had moved from one of them into another, but this meant that he was 
still a member of B.

I hope I've managed to explain that!

Thanks
Dave

________________________________
From: Shilen Patel 
<<mailto:>>
Sent: Thursday, October 19, 2017 6:50:14 PM
To: Dave Churchley
Cc: 
<mailto:>
Subject: Re: [grouper-users] Composite group problems

If both factors in the composite are being updated at about the same time for 
the same subject, then a membership may be missed.  For example, if Group A 
is an intersection of Group B and Group C and you add the same person to B 
and C at almost the same time, then due to the way the database transactions 
work, the composite membership may not be added to Group A.  Does that seem 
like the problem you're having?

If so, this can be corrected using bad membership finder.  You can 
automatically run it (e.g. every hour) using a built-in daemon though that's 
only available in 2.3.  Prior to 2.3, it can be run manually.

https://spaces.internet2.edu/display/Grouper/Bad+Membership+Finder+Utility<https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.internet2.edu_display_Grouper_Bad-2BMembership-2BFinder-2BUtility&d=DwMFAg&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=sWqutME58phurE0oO57Icg&m=tsS1OjqqKWsStlrGJSGvp6O9_yk_clLrVXi3KHBvl1M&s=woKym5g57JyUA8wGJ6VlZ5zMkdicw0CFPOpkn4WBpec&e=>

- Shilen

On 10/19/17, 11:56 AM, 
"
 on behalf of Dave 
Churchley<mailto:%20on%20behalf%20of%20Dave%20Churchley>"
 
<
 on behalf of 
<mailto:%20on%20behalf%20of%>>
 wrote:

    Good afternoon

    We've been using composite groups for a few years now, mainly using the 
complement operation with exclusion groups. Since the summer, we've also had 
a few intersection groups.

    We've not noticed any problems with group memberships until a couple of 
weeks ago. (That's not to say there definitely weren't any issues, but there 
certainly was not a noticeable impact.) At first it was just with the 
intersection groups but today we've seen it with a complement group, too.

    It looks like the composite isn't calculating its membership correctly. 
Editing the composite and resaving it forces it to recalculate the 
membership. We've been using this as a workaround but it's obviously not 
ideal. Some of these composite groups are critical to access control for 
various systems across the University, including physical access into 
buildings.

    Is this a known issue? Is there anything we can do about it? We're 
running Grouper v2.2.2. Is there a patch or a better workaround?

    Any help would be greatly appreciated as this is a big issue for us at 
the moment.

    Thanks in advance.

    Dave Churchley
    Newcastle University