Grouper Users - Open Discussion List

[Scott Koranda <>]

Hi,

I am helping manage a large Grouper deployment that manages a
number of groups for a campus, including groups that represent
course offerings ("course groups").

November 1 marks a "transition" from one set of course groups
to another. The result is a large amount of work for 3 loader
jobs that manage the course groups.

In the past earlier versions of Grouper, all running on the
same VM (no changes in the available resources have happened),
have ridden out this transition without issue.

Today, however, using Grouper version 2.3 was different. We
saw that the loader consumed all of the available JDBC
connections. The default was set in
grouper.hibernate.base.properties:

hibernate.c3p0.max_size = 16

This caused a number of loader jobs, including maintenance
jobs like CHANGE_LOG_changeLogTempToChangeLog, to be starved.

Stopping the loader and changing to

hibernate.c3p0.max_size = 32

made the issue go away.

My question is what might be different in Grouper version 2.3
that caused all of the JDBC connections to be consumed where
previously they were not? 

I am wondering if code has changed that causes the Grouper
loader to be more "aggressive" in how it processes "a lot of
work"?

I also note that we did not see this issue on the dev system.
That VM, however, has less CPU cores and memory available to
it, so I am wondering if that constrained the loader in some
way and prevented it from scaling up and exhausting the JDBC
connections?

I appreciate any input the Grouper team has.

Thanks,

Scott K