Grouper Users - Open Discussion List

[Carl Waldbieser <>]

Shilen,

I think I figured out what had happened.

It looks like I had a circular dependency in my groups:

 * A = A_allow - A_deny
 * A_allow = X + B
 * B = B_include - B_exclude
 * B_exclude = Y + A

This last line was actually a mistake.  It should have been "B_exclude = Y".  
The upshot was, when I added "B" to "A_allow", "B" was already in an unstable 
state.  I'm not sure how Grouper tried to resolve this, but I'm not surprised 
that the operations seemed to take a long time.

Thanks,
Carl Waldbieser
ITS Identity Management
Lafayette College

----- Original Message -----
From: "Shilen Patel" 
<>
To: "waldbiec" 
<>
Cc: "grouper-users" 
<>
Sent: Monday, April 30, 2018 3:12:33 PM
Subject: Re: [grouper-users] Add composite as member takes really long time - 
MariaDB

Hi Carl,

Are you able to reproduce this issue using GSH and while it’s hanging, do a 
‘kill -3’ or jstack and send the stacktrace so we can see where the problem 
is?

Thanks!

- Shilen

On 4/30/18, 11:42 AM, 
"
 on behalf of Carl Waldbieser" 
<
 on behalf of 
>
 wrote:

    
    I experienced a strange error in Grouper this morning.
    I have my standard "allow" and "deny" groups for a policy.  I wanted to 
add a cohort to the allow policy, but there were some particular exclusions I 
needed to apply to the cohort list I was provided.
    I created a reference group for the provided cohort, and a reference 
group for the exclusions, and then I created a composite group that was the 
provided cohort minus the exclusions.  So far so good.  The composite ended 
up having 247 members.
    
    Next, I attempted to add this composite to my "allow" policy.  This ended 
up timing out in the UI.  I tried adding the composite to the "allow" policy 
using GSH, and after a short period of time, I received a stack trace.  In 
the Grouper logs, I saw:
    
      ERROR JDBCExceptionReporter.logExceptions(234) -  - Lock wait timeout 
exceeded; try restarting transaction
    
    I contacted our DB admins.  The DB admin found a lock originating from a 
sleeping Grouper process and killed it.  I tried to re-run from GSH again 
while the DB admin monitored the progress.  This time the query ran for 10 
minutes.  The DB admin could see it had created a temp table while holding 
~50,000 row locks.  
    
    At this point I terminated the client connection and the transaction 
rolled back on the DB side.  I exported the composite group membership to a 
spreadsheet, then imported the membership into a "workaround" reference 
group.  I was able to add this workaround group to the "allow" policy without 
any issues, and it took only a second or two for the operation to complete 
using the UI.
    
    I tried searching the Jira for this issue, but I didn't turn up any 
results.  Has anyone run into an issue similar to this?  We are running 
Grouper 2.2.1 with a MariaDB cluster back end.
    
    Is there any reason why adding a composite caused the issue vs. adding a 
static cohort?
    
    Thanks,
    Carl Waldbieser
    ITS Identity Management
    Lafayette College