Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Bad Memberships in Composite group

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Bad Memberships in Composite group


Chronological Thread 
  • From: Shilen Patel <>
  • To: Peter DiCamillo <>, "" <>
  • Subject: Re: [grouper-users] Bad Memberships in Composite group
  • Date: Wed, 14 Sep 2016 14:16:00 +0000
  • Accept-language: en-US
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:tfOr8BIw4Khlx2J2+9mcpTZWNBhigK39O0sv0rFitYgULP/xwZ3uMQTl6Ol3ixeRBMOAtKIC1rGd6v2ocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWapAQfERTnNAdzOv+9WsuL15z2hKiO/MjrbhlFnnKRYJh7KRSyqQKZ4vEbnYZ4HYow4RLMo39MfMxc32R3IxSekwuqoo/684Rk7jxdobc87MNaSo37ebg1V7pVEG5gPmworoW/ugPEUBOC/D4BSWgMiTJJBRTI9hf3Qs23vyfn4LlTwi6faPb2TLQ5X3ya5rtmTFe8kycGMzM/2G3KicE2ga5G9kHy7ydjypLZNdnGfMF1ebnQKJZDHTJM
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

The composite issue seems to be the most common type of bad membership issue.  But there are other types as well.  But what's reported in the daily report are the same issues that can now be automatically fixed by the 2.3 patch.

Thanks!

- Shilen

From: Peter DiCamillo <>
Date: Wednesday, September 14, 2016 at 10:09 AM
To: "" <>
Subject: Re: [grouper-users] Bad Memberships in Composite group

Are these the bad memberships that are listed in the Grouper daily report, or are those something else?

Peter

On 9/14/16 9:56 AM, Shilen Patel wrote:
So the problem is that there are two transactions running concurrently.  The first transaction deletes the user from userGrp1.  That transaction sees that the user is no longer in the base group so the composite is deleted.  The second transaction, running at basically the same time, adds the user to userGrp2.  That transaction sees that the user is already in the base group because it doesn't see the changes that the first transaction is making.  So the end result is that the user isn't in the composite anymore when it should be.

When we had this issue at Duke (I was getting multiple issues every day), what I did was just add locking at the caller to prevent concurrent updates.  Not good for performance, but it had solved the issue for the time being.  If you're using the grouper loader, than having multiple threads can also do this.

More recently, in a 2.3 patch, there's now an option to schedule finding and fixing these issues automatically.


Thanks!

- Shilen


From: Blair Christensen <>
Date: Wednesday, September 14, 2016 at 9:44 AM
To: Kumi Hagimoto <>
Cc: "" <>
Subject: Re: [grouper-users] Bad Memberships in Composite group

I've seen this in our environment with a similar group setup, first in 1.6.x and now on 2.2.2.

For now we just regularly run the Bad Membership Finder Utility to fix them but at some point I'd like to dig deeper and identify/resolve the actual problem.

blair @ uchicago


On Tue, Sep 13, 2016 at 5:21 PM, Kumi Hagimoto <> wrote:
Hello,

We've been getting bad memberships reported in the nightly reports since we've
created a composite group and would like to figure out the cause.

One of the groups that constitutes the composite group is a result of multiple
layers of group memberships rolled up.    At the very bottom layer are groups
that define different types of users, and it seems that the membership change
from one group to another in this layer may be the cause of this bad
membership.  Here's a simplified structure:

Composite Group
    |        \
 Base      Excludes
    |
  userGroups
    |           \
  userGrp1   userGrp2  ...


A user was deleted from userGrp1 and added to userGrp2 - timestamp less than a
second apart.  We got the Bad Memberships reported that night, and the user
was no longer in the Composite Group but still in the "Base" group.  This
happened for a few users, and all of them had a group change like this
example.  We checked the logs and there has been no error reported.   Has
anyone seen this sort of behavior?  If so, was there a fix for it?  We're
running grouper v 2.2.1.

Thanks,
Kumi





Archive powered by MHonArc 2.6.19.

Top of Page