Grouper Users - Open Discussion List

[Scott Koranda <>]

> There are no new rows for this patch, but there were a few attribute
> assignments added to loaded groups from a previous patch.  There are
> no audits or point in time associated with the attributes which change
> each time the loader runs for the job in this patch.  We have worked
> hard to make sure this is as lightweight as possible and Grouper
> assumes they are there.  Added some metadata on groups is not on my
> radar as something that needs to be optional for performance reasons.
> Ok?  :)

I think there is an issue, however, that will impact performance right
after the patching.

After patching and starting up the loader I see a couple of million new
rows added to GROUPER_CHANGE_LOG_ENTRY_TEMP. Those rows include things
like 'etc:attribute:loaderMetadata:grouperLoaderMetadataLoaded' and
'etc:attribute:loaderMetadata:grouperLoaderMetadataLastFullMillisSince1970'.

Since all of those rows have to be processed and moved from
GROUPER_CHANGE_LOG_ENTRY_TEMP to GROUPER_CHANGE_LOG, and then the
various change log consumers have to process each of those rows, any
"real" changes in group memberships are not going to be processed for
quite some time.

My plan to avoid this is:

- make sure all "real" work is processed
- stop the loader
- delete loader jobs
- patch
- start the loader
- wait for the change log temp to stop growing
- stop the loader
- truncate GROUPER_CHANGE_LOG_ENTRY_TEMP
- truncate GROUPER_CHANGE_LOG_ENTRY
- re-create the loader jobs
- start the loader

Will that work to avoid the extra millions of rows in the change log?

Thanks,

Scott K