Grouper Users - Open Discussion List

[Carl Waldbieser <>]

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