On 5/7/2012 5:46 PM, chwjim wrote:
>
> In iManager (not using Designer for this other than to import / deploy
> the drivers), the base DN for the subtree search for new requests is set
> to the "O" object. ("o=chwidv) The DN for the GCV doesn't seem to be


Good, eliminates that possibility.

> the problem. The RRSD is picking up "old" requests, - just not new
> ones... as shown by the trace here:
>
> [05/07/12 14:21:49.102]:RR ST:Received state change event.
> [05/07/12 14:21:49.103]:RR ST:Transitioned from state
> '%+C%14CStarting%-C' to state '%+C%14CRunning%-C'.
> [05/07/12 14:21:49.103]:RR ST:Successfully processed state change
> event.
> [05/07/12 14:22:00.022]:RR :RES_TIMER: Checking for workflows to be
> retried...
> [05/07/12 14:22:00.024]:RR :RES_TIMER: Cleaning up processed requests
> older than 7 days...
> [05/07/12 14:22:00.041]:RR :TTL: Checking for pending role requests...
> [05/07/12 14:22:00.042]:RR :TTL: Checking for workflows to be
> retried...
> [05/07/12 14:22:00.043]:RR :TTL: Checking for expired role assignments
> for identities contained under: o=chwidv
> [05/07/12 14:22:00.043]:RR :TTL: Cleaning up processed requests older
> than 7 days...
> [05/07/12 14:22:00.044]:RR :TTL: Cleaning up requests which no longer
> have a source DN
> [05/07/12 14:22:00.045]:RR :TTL: Checking for abnormally terminated
> approval workflows...
> [05/07/12 14:22:00.051]:RR :RES_TIMER: Cleaning up requests which no
> longer have a source DN
> [05/07/12 14:22:00.055]:RR :RES_TIMER: Checking for abnormally
> terminated approval workflows...
> [05/07/12 14:22:00.056]:RR :RES_TIMER:
> CN=20120329120842-e00485c96f744e959c334a966c77fb45-0
> [05/07/12 14:22:00.057]:RR :RES_TIMER:
> CN=20120329120842-40084caa2746442d9bd6db11b550988d-0
> [05/07/12 14:22:00.058]:RR :RES_TIMER:
> CN=20120327104729-b1fa6fa85dbe46febd14e1136d787b6c-0
> [05/07/12 14:22:00.060]:RR :RES_TIMER:
> CN=20120327101704-0cab53127f544d96ae08713b54efc7b6-0
> [05/07/12 14:22:00.061]:RR :RES_TIMER:
> CN=20120301062009-5ebbc5a8968344d29c10ab463b44bd51-0
> [05/07/12 14:22:00.062]:RR :RES_TIMER:
> CN=20120113145810-6f6f7e345fb844158fb3234e4415ffa8-0
> [05/07/12 14:22:00.063]:RR :RES_TIMER:
> CN=20111216073316-503c8811c688432aaaa19f9a5e37b5de-0
> [05/07/12 14:22:00.321]:RR :RES_TIMER:
> CN=20110909154956-09947972082f4cbcb08642ff6971596a-0
> [05/07/12 14:22:00.335]:RR :RES_TIMER:
> CN=20110825114106-6c132afb2be2426cbc4833b2832601fb-0
> [05/07/12 14:22:00.362]:RR :RES_TIMER:
> CN=20110825113111-c29c76778ec148d09403833407b48402-0
> [05/07/12 14:22:00.377]:RR :RES_TIMER:
> CN=20110825112959-f278bedfce72428785303ee816630c13-0
> [05/07/12 14:22:00.394]:RR :RES_TIMER:
> CN=20110825112946-2b1948d556e24294a5c087ebf4533f2c-0
> [05/07/12 14:22:00.409]:RR :RES_TIMER:
> CN=20110825112938-76aa4834d8524da79592217af14eee19-0
> [05/07/12 14:22:00.437]:RR :RES_TIMER:
> CN=20110825112902-d16c332f78e5424c9e2ce0da23fc667f-0
> [05/07/12 14:22:00.459]:RR :RES_TIMER:
> CN=20110825112825-3f314ac2a644416c8e376885cf0534f5-0
> [05/07/12 14:22:00.481]:RR :RES_TIMER:
> CN=20110825112804-fcc7b0273f354984aafef6d93ff79c26-0
> [05/07/12 14:22:00.508]:RR :RES_TIMER:
> CN=20110825104004-6e496eeb54264bee8bd3186c9eb75f20-0
> [05/07/12 14:22:00.523]:RR :RES_TIMER:
> CN=20110825103929-c9c9dad110704ff2a64fdea73dfb99dc-0
> [05/07/12 14:22:00.559]:RR :RES_TIMER:
> CN=20110825103909-646b1009068940a4ace0a80b799bb55d-0
> [05/07/12 14:22:00.577]:RR :RES_TIMER:
> CN=20110825103726-fe7f56149878423b9abf98e21392e067-0
> [05/07/12 14:22:00.599]:RR :RES_TIMER:
> CN=20110825103319-5c96392ee9e34f2584754955f74089ff-0
> [05/07/12 14:22:00.620]:RR :RES_TIMER:
> CN=20110825103259-3ff678edc91b4f989059df49bf63300f-0
> [05/07/12 14:22:00.641]:RR :RES_TIMER:
> CN=20110825102857-bb12e5b28af4490195932bdd863077ab-0
> [05/07/12 14:22:00.660]:RR :RES_TIMER:
> CN=20110825102700-93b0debfa5204c37b6794d31a5a0daa3-0
> [05/07/12 14:22:00.683]:RR :RES_TIMER:
> CN=20110825102210-919a2afbc7324211ba01251796b0dbc7-0
> [05/07/12 14:22:00.703]:RR :RES_TIMER:
> CN=20110825102035-54ee486a00724b0c91d7966c23ec0008-0
> [05/07/12 14:22:00.725]:RR :RES_TIMER:
> CN=20110824151749-acd886a79d6445f9bd3b85ead52ba5f2-0
> [05/07/12 14:22:00.748]:RR :RES_TIMER:
> CN=20110824151451-0c851303fdd8418a996190dab5059ae9-0
> [05/07/12 14:22:00.763]:RR :RES_TIMER:
> CN=20110729120946-0d01b77f69dc48eda3cd2bb2ea8911d9-0
> [05/07/12 14:23:00.019]:RR :TTL: Checking for pending role requests...
> [05/07/12 14:23:00.020]:RR :TTL: Checking for workflows to be
> retried...
> [05/07/12 14:23:00.021]:RR :TTL: Checking for expired role assignments
> for identities contained under: o=chwidv
> [05/07/12 14:23:00.037]:RR :RES_TIMER: Checking for workflows to be
> retried...


> As far as the partition information, this QA environment is a single
> server tree, so there isn't much possibility of not having access to the
> correct partition; unless there is some stale information stored
> somewhere in the driver data regarding the "old" server that this
> environment was rebuilt from....?? There is a partition on the
> driverset, - are you saying to partition again at the User App driver?


No, just to ensure that the data we need events from, is within the
partitions contained on this servers set of replicas, which you have.

Ok, next, the RRSD driver works in two ways. 1) Event driven, 2)
Polling for time related stuff.

So cause another event, and lets see if anything shows up in the RRSD
trace. I.e. Generate another Request object via User App.



>