https://bz.apache.org/bugzilla/show_bug.cgi?id=66660

            Bug ID: 66660
           Summary: StaticMember doesn't support lazy hostname resolution
                    (useful in K8s)
           Product: Tomcat 9
           Version: 9.0.x
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Cluster
          Assignee: dev@tomcat.apache.org
          Reporter: diego.riv...@armedia.com
  Target Milestone: -----

In many (most) vendor-provided K8s environments, UDP is not allowed to be used
within clusters. Thus, one is forced to use static TCP member lists pointing to
all the pods that will be members of the cluster:

<!-- Cluster with 3 members: pod-0, pod-1, and pod-2 -->
<LocalMember .../> <!-- this is pod-0 -->
<Member host="pod-1" ... />
<Member host="pod-2" ... />

If, for whatever reason, there's a need to boot up the pods in OrderedReady (as
opposed to Parallel), then pod-0 will be booted before the others, and the
StaticMember implementations will fail to resolve the hosts "pod-1" and
"pod-2", because they will not exist in K8s DNS yet (b/c the pods won't exist
until the first pod is in the Ready state).

Thus, the first pod will be left with a broken member list: later on the
members will be there, but since they weren't around during initialization, the
member list is left empty.

Instead of caching the hostname once on construction, the IP address
(getByName() result) should only be cached if the member is confirmed to be
healthy. If the member is initializing, then it's OK to resolve the hostname
every time (perhaps add an attribute to limit the number of hostname resolution
retries?). If the member is down and being polled for health it's Ok to resolve
the hostname every time as well.

One possible solution is to encapsulate MemberImpl.host in a method that does
the lookup and caching/de-caching based on the member's state.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to