Grouper Developers Forum

["Black, Carey M." <>]

All,

I have started trying to deal with a change log consumer and "[group/stem] 
name changes". I have taken a stab at this in the past, but did not get very 
far. This time I kind of have it working, but I don't like what I am seeing. 
So I am guessing that either, or both, of these things are true at this point.
        1) I am the only one doing this
        2) I am doing something wrong

I will point out that:
         I am working in the v2.3 universe.
        I had to write some code ( AKA: isStemMarkedForSync(PITStem 
parentFolder, PITAttributeDefName pitSyncAttribute) ) that uses 
"GrouperDAOFactory.getFactory().getPITAttributeAssign()") to try to resolve 
attribute assignments in the ancestors of a group/stem. Needing to dive that 
deep into the Grouper API seems... wrong... but I found no other way to do 
it. So clearly I could be doing things incorrectly here. :)



What I appear to be seeing is this.

Order of events:

1) UI user deletes a group.
2) Change Log Consumer (CLC) runs before "temp change log" daemon job runs 
--> no events to process no problem.
3) "temp change log" daemon job runs  ( now there are queued CLC events to be 
processed )
4) Change Log Consumer (CLC) runs (again) after "temp change log" daemon job 
runs --> events to process so processing starts.
        Processing looks in PIT data for the "deleted group" and it finds it 
but only "sometimes".
        NOTE: If I throw an exception when the PIT group is not found then 
the next time the CLC runs it likely finds the PIT group.

Problem/Question #1: 
        So it appears that I don't understand how the state of the PIT data 
integrity ( with respect to the main repository integrity ) works from a 
timeline perspective.



Also I think this sequence of events also leads to other issues (like the 
intermediate states not making it into the PIT data at all.

1) UI user creates a group named "foo".
2) UI user renames group "foo" to "bar".
3) UI user renames group "bar" to "newFoo".

Problem/Question #2:
        If those events happen "fast enough" then the CLC would see events 
for all three, but the PIT data may never have the "foo" and/or "bar" group. 
( At least I have not been able to find a way to find those objects. )
        Even if the CLC throws several times the PIT data seems to never "get 
all of the state changes".
                Which can leave the CLC "throwing exceptions" and becoming 
"stuck" on a given CLC event that it appears to never recover from.


So a few direct questions:
        How is the PIT data constructed?
                From the CLC or directly from the main repository? ( and at 
what time/interval/process ? ) 
                        If it is from the main repository, that seems bad and 
likely to have "gaps" if changes are made quickly.
                        If it is from the CLC then I don't understand how 
what I am doing does not eventually find the data in the PIT. ( Maybe/likely 
it is my code trying to deal with PIT data.)

I suspect the answer is that the PIT data is constructed on some "time 
interval/batch" from the main repository and if enough changes happen in that 
repository fast enough then the PIT become blind to the intermediate states. 
Yet the CLC events have all of those intermediate states. 

-- 
Carey Matthew