eDir moves are not anything close to atomic and therefore have some
degree of unreliability built into them - I usually recommend against a
tree design that requires moves.

That said, at least one of your problems is of your own making. Your
extra "normal" sync is a result of the fact that your loopback driver
association state was already "migrate". This is probably because at
some point in the past you did a migrate, but the way you handle sync
events doesn't allow the event to get to the point the pipeline where
IDM would normally transition the state to "processed". You should be
able to remedy that by re-setting the association in your event
transformation as part of the handling of the sync event. Then to fix
all the existing stuck associations you could do a resync or do some
kind of one-off to clean them up.


sveldhuisen wrote:
> I know a lot of posts have been created regarding moves/ sync. However,
> this one is very exotic and is also pissing me off...
> I have an issue with a command/event interaction of two drivers. The
> first driver is a PeopleSoft driver that activates an identity via the
> Publisher channel by initiating a modify and a move (to an active
> container) command to the Identity Vault. A second driver (Loopback
> Password driver, Subscriber only) generates a Password upon this move
> event. The Password driver is able to consume move events by adding an
> assocation to the event and User object within the Subscriber ET. Both
> drivers are located on the master replica and the move operation is
> within one partition. No other drivers are running. IDM version is
> 3.6.15-20110908.
> The actual commands (modify + move) from the PeopleSoft driver (extract
> from trace level 3):
> '[XML] PeopleSoft Driver trace level 3 - Pastebin.com'
> (http://pastebin.com/D0qBrNnk)
> So far so good. However I notice two issues on the Subscriber Channel
> of the Loopback Password driver:
> 1) The IDM engine fires a regular sync
> 2) It seems that eDir/IDM does not handle the move atomic
> The actual input/output for the Loopback Password driver (trace level
> 3):
> '[XML] Loopback Password Driver trace level 3 - Pastebin.com'
> (http://pastebin.com/pGtRdySJ)
> -1) The IDM engine fires a regular sync-
> What I would expect as events on the Loopback Password Driver:
> - one or more sync events with @from-move='true'
> - one move event
> What I see in a trace level 3 of the Loopback Password Driver
> - one sync event with @from-move='true'
> - one cached sync event without @from-move='true'
> - one sync event with @from-move='true' combined with a move event
> Could anybody explain to me why I get a sync event without
> @from-move='true'? In my understanding this event should not happen,
> because this event is reserved for a regular sync (i.e. migrate from
> Identity Vault). What is the reason that a regular sync is fired and for
> what purpose?
> -2) It seems that eDir/IDM does not handle the move atomic-
> If you take a close look at the trace level 3 from the Loopback
> Password Driver something strange is happening with the cached sync
> event without @from-move='true' ([05/01/12 12:01:23.731]). If the DN of
> the sync event is used by the SrcQueryProcessor to read a couple of
> attributes, values are being returned nicely ([05/01/12 12:01:23.934]).
> If another policy rule further down the chain, uses the same DN by using
> the SrcCommandProccesor (issuing a modify-password), the command fails:
> Code(-9010) An exception occurred: novell.jclient.JCException: -601
> How is this possible? According to the SrcQueryProcessor the User is
> situated in the Active container([05/01/12 12:01:23.948]). When I use
> the same DN later on with the srcCommandProcessor it is not there
> (yet?). Now this gives me two nasty feelings:
> - moves are not atomic
> -the query is not always done on the replica that the IDM engine
> runs on
> I can't imagine that this is the case, so therefore I hope somebody
> could clarify this behaviour. This "feature" makes it quite impossible
> to handle a move event reliable. Any thoughts?