Grouper Users - Open Discussion List

[Tim Darby <>]

I had a similar thing with change log processing, so I tried advancing the psp sequence number in grouper_change_log_consumer.  However, when I restart gsh -loader, psp starts with a sequence number prior to the one I set, tries 100 sequence numbers past that and stops.  It now won't go past that point and acts like it's broken.  The other two consumers, syncGroups and grouperRules, are still being updated correctly, but psp is dead in the water.  Why is it looking at sequence numbers smaller than the one in grouper_change_log_consumer and what can I do to get it going again?

Tim Darby
The University of Arizona
Mosaic, Systems Integration and Architecture

UITS, Rm 335, 520-626-3799

On Wed, May 15, 2013 at 7:08 AM, David Langenberg <> wrote:

Hi Bryan,

The table grouper_change_log_consumer holds the pointer.  

Dave

On Wed, May 15, 2013 at 8:04 AM, Bryan E. Wooten <> wrote:

Dave,

Thanks for the explanation, that makes sense and adds to my understand of how the change log works.

Can you point me to the table I need to modify? (i.e. Where is the change log sequence number?)

Thanks,

Bryan

From: David Langenberg <>
Date: Tuesday, May 14, 2013 11:37 PM
To: Bryan Wooten <>
Cc: "" <>
Subject: Re: [grouper-users] PSP problem after folder rename

The PSP is trying to process this entry because BulkSync doesn't advance the PSP change log consumer to the most recent event.  Think of it this way, the PSP Change log consumer is pointing at change log sequence 100.  You then rename the stem, a bunch of change log entries are added, however, because the change log consumer isn't actively processing them the pointer is still at 100.  You then run the BulkSync.  BulkSync does an immediate calc/diff of grouper to your AD and performs the rename operation.  You then tell the change log processor to start processing.  It is still at sequence 100 and advances to the rename operation, let's call this sequence 105.  105 says rename from A to B.  However, BulkSync already performed that operation.  So when the consumer goes looking for A in AD, it doesn't find it and you get this error.  What should probably happen in this instance is the PSP attempt to see if the rename operation already happened (possibly schedule a full-calc of B to ensure that it did get correctly re-named instead of deleted by some other process).  

For now though, I recommend you advance the change log pointer for the PSP past this problem entry and let it continue processing.

Dave

On Tue, May 14, 2013 at 11:34 AM, Bryan E. Wooten <> wrote:

After renaming a folder and getting ./gsh  -psp –bulkSync to complete without errors my AD now reflects my Grouper folder and group structure accurately.

 

I added a folder using the UI and attempted to run: loaderRunOneJob("CHANGE_LOG_changeLogTempToChangeLog")

and loaderRunOneJob("CHANGE_LOG_consumer_psp").

 

But I get the following error:

 

- An error occurred processing sequence number 192889

edu.internet2.middleware.psp.PspException: edu.internet2.middleware.psp.PspNoSuchIdentifierException: Psp 'psp' - Has reference from 'PSOIdentifier[id='CN=uuCurrentEmployee,OU=groups,OU=TestStem,OU=uofu,OU=groups,OU=grouper,DC=testad,DC=utah,DC=edu',targetID=ldap,containerID=<null>]' to 'Reference[toPsoID=PSOIdentifier[id='CN=u0530608,ou=people,dc=testad,dc=utah,dc=edu',targetID=ldap,containerID=<null>],type=member]' SearchResponse[psos=0,status=failure,error=noSuchIdentifier,errorMessages={[LDAP: error code 32 - 0000208D: NameErr: DSID-0310020A, problem 2001 (NO_OBJECT), data 0, best match of:

        'OU=uofu,OU=groups,OU=grouper,DC=testad,DC=utah,DC=edu'

 

The OU TestStem is the folder we renamed and the bulk sync removed the OU from AD as expected.

 

It is unclear why there is still an entry for this folder in the Change Log. When this error occurs the Change Log Consumer stops processing so my new created folder does not get provisioned to AD.

 

Is this just a rogue entry in the Change Log? I am sure this is not the only one.  Should I just remove all the entries in the change log to fix this issue or is there a better solution?

 

Thanks,

 

Bryan

--
David Langenberg

Identity & Access Management

The University of Chicago

--
David Langenberg

Identity & Access Management

The University of Chicago