If there is a count for the "Failed at Resource" statistic using the status tool, verify the problem in the sync log. For example, if the status tool displays the following information:

             --- Ops Completed for 'DS1 to DS2' Sync Pipe ---
Op Result              : Count
-----------------------:------ 
Success                : 0
Out Of Scope           : 0
Op Type Not Synced     : 0
No Change Needed       : 0 
Entry Already Exists   : 0 
No Match Found         : 0 
Multiple Matches Found : 0 
Failed During Mapping  : 0 
Failed At Resource     : 1 
Unexpected Exception   : 0 
Total :1

This will register after a change is detected at the source in any of the following cases:

  • If the fetch of the full source entry fails. The entry exists but there is a connection failure, server down, timeout, or something similar.
  • If the fetch of the destination entry fails or if the modification to the destination fails for an exceptional reason (but not for "Entry Already Exists," "Multiple Matches Found," or "No Match Found" issues).

Verify the change by viewing the <server-root>/logs/sync file to see the specific operation. If any of the following result codes are listed , the server is experiencing timeout errors:

  • resultCode=timeout: errorMessage=A client-side timeout was encountered while waiting 60000ms for a search response from server server1.example.com:1389
  • resultCode=timeout: errorMessage=An I/O error occurred while trying to read the response from the server
  • resultCode=server down: errorMessage=An I/O error occurred while trying to read the response from the server
  • resultCode=server down: errorMessage=The connection to server server1.example.com:1389 was closed while waiting for a response to search request SearchRequest
  • resultCode=object class violation: errorMessage='Entry device=1234,dc=example,dc=com violates the Directory Server schema configuration because it contains undefined object class

With these "Failure at Destination" timeout errors, look at the following settings in the PingDirectory server to determine if adjustments are needed:

  1. For External Server Properties, check the connect-timeout property. This property specifies the maximum length of time to wait for a connection to be established before giving up and considering the server unavailable.
  2. For the Sync Destination/Sync Source Properties, check the response-timeout property. This property specifies the maximum length of time that an operation should be allowed to be blocked while waiting for a response from the server. A value of zero indicates that there should be no client-side timeout. In this case, the server’s default will be used. 
    $ bin/dsconfig --no-prompt --port 389 \
  --bindDN "cn=Directory Manager" \
  --bindPassword password list-external-servers \
  --property connect-timeout
    External Server         : Type             : connect-timeout : response-
                                                               timeout
------------------------:------------------:-----------------:-----------
server1.example.com:389 : sundsee-ds       : 10 s            : -
server2.example.com:389 : sundsee-ds       : 10 s            : -
server3.example.com:389 : ping-identity-ds : 10 s            : -
server4.example.com:389 : ping-identity-ds : 10 s            : -
  3. For Sync Pipe Properties, check the max-operation-attempts, retry-backoff-initialwait, retry-backoff-max-wait, retry-backoff-increase-by, retry-backoff-percentage-increase. These Sync Pipe properties provide tuning parameters that are used in conjunction with the timeout settings. When a Sync Pipe experiences an error, it will use these settings to determine how often and quickly it will retry the operation. 
    $ bin/dsconfig --no-prompt list-sync-pipes \
  --property max-operation-attempts --property retry-backoff-initial-wait
\
  --property retry-backoff-max-wait --property retry-backoff-increase-by \
  --property retry-backoff-percentage-increase \
  --port 389 --bindDN "cn=Directory Manager" \
  --bindPassword password