[controller] Fix bug in ProtocolVersionAutoDetectionService

[minhmo1620]

Problem Statement

During testing, we identified the following issues:

1. Leadership Check Fails on Startup

• Cause: initialDelay is set to 0, so the task runs immediately. This triggers a leadership check before the host is fully initialized.
• Effect: Although the host is the leader, it fails the check because it's not ready. The second retry usually succeeds.
• Solution: Increase the initialDelay to give the host time to complete setup before the check runs.

2. Protocol Mismatch in URL Comparison

• Cause: The controllerUrlToVersionMap uses http:// as keys, but incoming requestURLs are in https://.
• Effect: Lookup in the map fails due to the protocol mismatch, as no matching key is found.
• Solution: Use HTTP/HTTPS based on SSL Factory, and remove the protocol from the key string of controllerUrlToVersionMap

Solution

1. Increase the initial delay == sleep duration
2. Use HTTP/HTTPS based on SSL Factory, and remove the protocol from the key string of controllerUrlToVersionMap

Note: During the PR development time, I found one interesting symptom that requires me to disable SSL in integration test. However, HTTPs on production should work.

Issue: When we look for leader/standby in Helix, the port we see is HTTP port, and HTTPs port is defined by multiClusterConfig.

On production, we have different host and the SAME port number. However, at local, we have SAME host (localhost) and different port for different controllers.

When we have Instance, we can get the URL by getUrl(https). The issue is that getUrl(true) will return the same url for any controller with the same host (localhost) and the same port (multiClusterConfigs.getAdminSecurePort()). When getUrl(false) we wont have issue because the port in Helix is respected.

Hence, I need to disable HTTPs in integration test, else, the request will be routed back to leader.

Code changes

• Added new code behind a config. If so list the config names and their default values in the PR description.
• Introduced new log lines.
  • Confirmed if logs need to be rate limited to avoid excessive logging.

Concurrency-Specific Checks

Both reviewer and PR author to verify

• Code has no race conditions or thread safety issues.
• Proper synchronization mechanisms (e.g., synchronized, RWLock) are used where needed.
• No blocking calls inside critical sections that could lead to deadlocks or performance degradation.
• Verified thread-safe collections are used (e.g., ConcurrentHashMap, CopyOnWriteArrayList).
• Validated proper exception handling in multi-threaded code to avoid silent thread termination.

How was this PR tested?

• New unit tests added.
• New integration tests added.
• Modified or extended existing tests.
• Verified backward compatibility (if applicable).

Does this PR introduce any user-facing or breaking changes?

• No. You can skip the rest of this section.
• Yes. Clearly explain the behavior change and its impact.

[huangminchn]

Thanks for quick fix, Minh!