AD Changelog Stuck on Iterating
(too old to reply)
2010-02-09 21:59:38 UTC

I get an occasional error when feeding in AD changes from ADChangelog
v2, When I iterate in and have no "iteratorStateKey" It runs through
no problems, but if i add a state key and run sometimes it will sit on
"Iterating" and every few minutes it will say "[AD] CTGDJF012I
Connector is restarting. Will get start USN value from restart data".
but other times it will run fine and use the iteratorStateKey as it
should. Has anyone encountered this? If I clear the Key it runs from 0
Looking in System Stores I can see my key and it has a valid value. I
am running TDI 6.1.

Thanks =)
Eddie Hartman
2010-02-12 08:48:47 UTC
What are you using for your System Store? Also, do you
have Auto Reconnect turned on for the AD Change Connector?
This is in the "Connection Errors" tab. If so, then this
could be due to the connection going down.

What do you see if you enable Detailed Log for the Connector
and then run it?

2010-02-14 22:25:47 UTC
Hi Eddie

I am using jdbc:derby on the localhost for my system store and yes I
do have auto Reconnect turned on.

From what I can see If I delete the keystore and start from zero again
it runs fine if I stop it halfway through then start it again it
starts again fine. The issue I am seeing is if i let it continue to
Iterate till it get to the most up to date USN then when I start it
again it the USN seems to be too high and is set higher than what the
current USN is.

I noticed this when I let it run through on friday and then stopped it
when it got to the latest USN which was 446069667, then today I ran
the AL again and it sat in Iteration without processing anything. I
then deleted the keystore and let it run again this time it got to the
latest USN which was 318712093 so when it started this morning it was
looking for the next number after 446069667 but AD was actually only
around 318712093.

What would cause it to get so far ahead of itself?

2010-02-15 00:39:41 UTC
Wait scratch that, it looks like the USN was correct as it is now past
USN 446069667.

So it looks like it pulls the right USN it just wont iterate on it
sometimes. it will just sit there.

So now I see it pulling the right USN at startup

13:37:55 [AD] CTGDJF015I Will read start USN values from System
Store. Parameter: express.
13:37:55 [AD] CTGDJF018I Start USN value: 451365143.
13:37:55 [AD] CTGDIS158I Registering Script Beans.
13:37:55 [AD] CTGDIS484I Connector
com.ibm.di.connector.ADChangelogConnectorv2: 2.0-di6.1.1
13:37:55 [AD] CTGDIS046I Initialization finished.
13:37:56 CTGDIS087I Iterating.

But will not process any records from here.
Eddie Hartman
2010-02-15 09:36:00 UTC
Please open a PMR on this. If the AD Change Connector
(I hesitate to call it "changelog" :) then we definitely need to
sort it out. Could be a combination of settings that you are

Either way, would you mind letting me know how this turns out?

2010-02-15 22:13:11 UTC
After further testing I seem to have found the cause of my issue.

I had my "LDAP URL" set to connect to my general domain which was
returning the first Domain Control server to respond. As we have
multiple DC Servers I was not getting the same server responding every
time. Each of these servers has different USN numbers for events and
when it would get up to date on one, the next connection may connect
to a different DC and sit and wait for a USN that may be a long way

To get around this I have changed my "LDAP URL" to only talk to one DC
our primary DC and it looks to be working alot better today.

Thanks for taking the time to assist me in this issue Eddie.

Eddie Hartman
2010-02-16 08:50:30 UTC
Just a pleasure. I am SO glad to hear you solved this :)
And shared your solution.


Continue reading on narkive: