Grouper Users - Open Discussion List

[Carl Waldbieser <>]

Shilen,

I actually cannot reproduce the behavior, now.  I tried it again, and now the 
composite group adds easily.
I am at a loss to explain why the process seems almost effortless, now.

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