Grouper Users - Open Discussion List

[Shilen Patel <>]

That’s a good catch.  We do handle some forms of circular dependencies, but 
not this.  If you add somebody to B_include in this example, you run into an 
infinite loop (well until you get a java.lang.StackOverflowError).

- Shilen

On 5/1/18, 1:18 PM, "Carl Waldbieser" 
<>
 wrote:

    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