directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject AP handling : When problems start to pop their nose...
Date Mon, 10 Jan 2011 23:59:19 GMT

I'd like to inform you about the current status, and the problem I'm 
currently facing.

So far, I was able to implement the AP handling using some kind of 
revision numbers (I think I have explained extensively how it works 
those past 2 months). This approach is quite promising, as it allows us 
to avoid a costly update of the backend when some Subentries are 
modified. The Add, Delete, Search and Lookup operations are implemented, 
and part of the rename operation.

Today, as I was working on the rename operation, fixing a few issues 
here and there (SubentryCache weren't thread safe), I faced some dire 
issue : the ChangeLog mechanism came into the mechanism like a stick in 
the wheels. Let me explain.

When you apply some modification on some entry, we compute the revert 
operation in the ChangeLog Interceptor, in order to be able to apply it 
when reversing the operations. It works wonderfully in most of the case, 
except in some corner cases we are aware of (typically, when adding an 
entry, creating an alias on this added entry, removing the entry - and 
then the alias is pending, but this is legal - and removing the alias. 
If we revert these 4 operations, the addition of the pending alias will 
not be accepted).

Now, I have another issue, which is quite similar :
- I add a SAP
- I add an entry
- I add a subentry associated with the SAP which select the entry with a 
CollectiveAttribute role
- I do a lookup o the entry, which modify the entry to point on the subentry

So far, so good. Now, when the revert operation starts, it does :
- remove the subentry, leaving the entry with a reference to the removed 
- try to remove the entry, which does a read of the full entry, which 
tries to add the CollectiveAttribute using the reference to the removed 
subentry, leading to a NPE.

Sounds not very good, isn't it?

I still have options :
- when we delete the entry, we do a lookup in the eagerlyPopulateFields, 
which tries to inject the collectiveAttribute into the entry : why ? I 
see no reason to do such a thing (I'm not sure either that most of the 
interceptors the lookup is going through are to be executed. To be 
double checked)
- I can add some extra checks in the CollectiveATtributes to deal with 
this specific case, ie if the reference to a subentry exists and if the 
entrySeqNumber is above its AP seqNumber, then I don't update the 
CollectivAttribute (yuk :/)
- ultimately, we can also change completely our startegy and decide to 
update all the entries immediately when doing an operation on a subentry.

I will investigate the first option atm, which sounds the most 
productive, but still, we may have to consider some more global 

I will keep you updated.

Emmanuel L├ęcharny

View raw message