Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Upgrade errors 2.2.1 -> 2.2.2

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Upgrade errors 2.2.1 -> 2.2.2

Chronological Thread 
  • From: Baron Fujimoto <>
  • To: Chris Hyzer <>
  • Cc: Grouper Users <>
  • Subject: Re: [grouper-users] Upgrade errors 2.2.1 -> 2.2.2
  • Date: Thu, 29 Oct 2015 09:42:06 -1000

On Thu, Oct 29, 2015 at 06:49:47PM +0000, Chris Hyzer wrote:
>> After patching 2.2.1, downloading, and unpacking the new
>> grouper.apiBinary-2.2.2, I accepted the recommendation to run a script
>> that copies change log temp records to the change log. This ran for hours,
>> and was still running when I left for the day.
>> When I returned this morning, I was greeted with the error below[*],
>> followed by the advisory that,
>> =====
>> You need to revert all patches to upgrade
>> ################ Checking patch grouper_v2_2_1_api_patch_21
>> Patch: grouper_v2_2_1_api_patch_21: was applied on: 2015/08/10 13:41:24"
>> =====
>> I'm unsure what remedial steps are actually needed now. grouperInstaller
>> looks like it wants to resume from or retry grouper_v2_2_1_api_patch_21.
>> Should I just let it continue, or do I need to "revert *all* patches" as
>> displayed and start over?
>Do you run the grouper loader which copies change log temp to change log
>continuously? Were there a lot of records unprocessed in grouper change log
>temp table? You need to run a grouper loader process for grouper to
>function correctly. It is part of the standard upgrade to uninstall all
>2.2.1 patches to get to 2.2.2. So let it revert all the 2.2.1 patches, you
>can answer yes to each one or revert all at once.

Hmm, no we're not running a grouper loader. I wasn't aware of this
requirement. Did I miss it in the documentation somewhere? The wiki
page for Grouper Loader seems to describe it in terms of a provisioning
system, and not something needed for regular/ongoing operation. We've been
provisioning and maintaining all of our groups via the WS.

Where is this maintenance aspect of the change logs described?

>> Is the amount of time being taken to copy the change logs reasonable? I
>> think our db goes down nightly for a backup. If the the copy change log
>> process can't complete before that happens, will it resume from a previous
>> partial completion, or does it need to start all over from the beginning?
>> I'm concerned about the possibility that may never complete given the
>> db's backup downtime constraint.
>I don't know, how many records were there? Yes, it is not one large
>transaction, it will make progress, and if you stop it and restart it will
>pickup from where it left off. Do some record counts while it runs and see
>it making progress.

Are these the right tables?

select count(*) from grouper_change_log_entry; -> 419750
select count(*) from grouper_change_log_entry_temp; -> 3988004

So, maybe yikes.

Could this also be the reason why we occasionally see audit log requests
time out?

Baron Fujimoto
:: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

Archive powered by MHonArc 2.6.16.

Top of Page