https://bz.apache.org/bugzilla/show_bug.cgi?id=66660
--- Comment #3 from Diego Rivera <diego.riv...@armedia.com> --- (In reply to romain.manni-bucau from comment #1) > Hi, probably not yet mainstream but did you evaluated to use a custom DNS > resolver impl delegating to the JVM when the host values were not known to > be the pod ones? (https://bugs.openjdk.org/browse/JDK-8263693). Think it > makes this usage quite straight forward, just requires to add the custom > impl in tomcat launching classpath (with bootstrap.jar - or directly in the > jvm classpath if embedded) and be it. Can avoid to put a specific strategy > in tomcat and test with the more appropriated one before potentially giving > it back, wdyt? That wouldn't help. The problem is *when* the DNS resolution happens, not "by whom". The MemberImpl code does the resolution during construction and expects to store the IP address data - whatever it is - at that point. If resolution fails, construction fails and thus the member isn't added to the cluster - i.e. there's no provision for an "expected member": the member's hostname is required to exist at the moment the object is instantiated. Naturally we can't add an IP address b/c no such address exists yet (or else we'd already have a hostname). -- 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
