From Veterans Affairs: User Sync Tool should have the logic built-in to attempt to connect to multiple IP addresses when one fails
mmiddlet opened this issue · 5 comments
DNS and domain controllers are designed to be redundant and fault-tolerant systems. When one DNS server or domain controller is unavailable, typically application software is designed with that redundancy in mind. So, if a connection to a single DNS server or domain controller fails, ideally the application should have the intelligent logic coded in to attempt to connect to an alternate DNS server or domain controller. However, the Adobe User Sync Tool code doesn’t appear to have this extra logic built-in to it. When a domain lookup (such as adobe.com) resolves to multiple IP addresses, the Adobe User Sync Tool appears to choose one IP address and attempt to connect using LDAP. If the LDAP connection fails, the Adobe User Sync Tool appears to fail and exit, and does not run to completion.
If looking up (resolving) the LDAP server address returns multiple IP addresses, the User Sync Tool should have the logic built-in to attempt to connect to multiple IP addresses. So if the LDAP connection to the first IP address fails, then another LDAP connection attempt should be made to a second or third IP address before the job fails and exits. Suggested feature request for when LDAP connection fails. One way to address this “single LDAP connection failure” issue would be to allow the user to specify an alternate LDAP connection in the YML file. Maybe something like this:
host: "ldaps://server1.domain.com:3269" [that’s the current format]
And then maybe some second line like one of these?
host2: "ldaps://server2.domain.com:3269"
host-alt: "ldaps://server2.domain.com:3269"
alt-host: "ldaps://server2.domain.com:3269"
This second line (host2, host-alt or alt-host) would only be used if the primary host connection fails.
Instead of trying one code and giving up, try another connection. That might be simpler to implement, and would allow the user to specify the desired behavior. This would be somewhat like specifying a primary and secondary DNS server, which is a common practice.
Connectivity issues should generally be managed on the network side, not in the UST itself. I recommend connecting the UST to a load balancer or global catalog domain.
One thing we can do, however, is add a simple timeout and retry mechanism to give the UST a chance to reconnect to the configured host before failing completely.
I understand the customer's concerns. Perhaps this is something to consider in the future, but is not something the development team is looking at doing at this time.