Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Defining rule-based group privileges?

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Defining rule-based group privileges?

Chronological Thread 
  • From: Shilen Patel <>
  • To: Peter DiCamillo <>
  • Cc: Chris Hyzer <>, Gagné Sébastien <>, "" <>
  • Subject: Re: [grouper-users] Defining rule-based group privileges?
  • Date: Thu, 31 Jan 2013 20:48:31 +0000
  • Accept-language: en-US

OK I think that explains the problem. With includeFlattenedPrivileges
set, the change log processor is trying to insert 800K records into the
change log table since there are 800K new flattened privileges.


-- Shilen

On 1/31/13 3:01 PM, "Peter DiCamillo"

>Thanks, I'll try changing includeFlattenedPrivileges, it's set to true
>now. I tested by adding a person to the group that is used for
>privileges. We have about 800,000 course groups, since we have to keep
>the course memberships for at least five years.
>On 1/31/13 1:08 PM, Shilen Patel wrote:
>> The delay may be in creating change log entries for the flattened
>> privileges. In the file, what do you have
>> changeLog.includeFlattenedPrivileges set to? If it's true and you don't
>> care about flattened privileges, set that to false and see if it
>> the issue. However, in either case, I wouldn't think it would take an
>> hour to do this. Is the member (that's being added to the group which
>> privileges to all the course groups) a person or a group? How many
>> groups are there?
>> Thanks!
>> -- Shilen
>> On 1/31/13 9:40 AM, "Peter DiCamillo"
>> <>
>> wrote:
>>> On 1/30/13 5:55 PM, Chris Hyzer wrote:
>>>>> We've encountered performance problems when assigning the members of
>>>>> group
>>>>> privileges to thousands of groups,
>>>> I think that was on an old version of Grouper, this is not a problem
>>>> anymore, right?
>>> I do still see one problem. If we make a change to the membership of
>>> group that has privileges for all the course groups, entries in the
>>> change log temp table are not processed for a very long time. For
>>> Grouper 2.1, I stopped timing it after an hour. It took several hours
>>> for 1.6. We use a change log consumer for near real-time provisioning,
>>> so that's a problem. In some cases, users are making requests to access
>>> a service, and expect to get access within about 10 minutes. The only
>>> solution I have is to handle changes to that group as a maintenance
>>> activity.
>>> Peter

Archive powered by MHonArc 2.6.16.

Top of Page