3.4 was end-of-life before Java 17 was released, so I don't think you can reasonably expect 3.4 to work on Java 17. If you're trying to run on Java 17, you should use one of the currently maintained releases.
That said, I think this is a bug that was fixed in 3.5, because something in ZooKeeper was parsing addresses based on InetSocketAddress.toString() or InetSocketAddress.getHostString() or similar, and that method's implementation changed in upstream Java. I had thought it was in Java 9, but it may have been in Java 14 (https://bugs.openjdk.java.net/browse/JDK-8232369). I can't find the ZOOKEEPER JIRA issue or git commit that fixed it, though, but I'm pretty sure it's fixed in 3.5 and later, because I haven't seen it with 3.5.9, which I've been using. On Thu, Nov 4, 2021 at 11:56 AM Bram Van Dam <bram.van...@intix.eu> wrote: > > Hey folks, > > Was trying to get ZK 3.4.14 (don't ask..) to run on Java 17. The server > seemed to start just fine, and responded to ruok, but basically nothing > worked. > > After a bit of poking around, while debugging SimpleSysTest, I got the > following stack trace: > > IllegalArgumentException: Unable to canonicalize address > localhost/<unresolved>:2181 because it's not resolvable > at > org.apache.zookeeper.SaslServerPrincipal.getServerPrincipal(SaslServerPrincipal.java:65) > at > org.apache.zookeeper.SaslServerPrincipal.getServerPrincipal(SaslServerPrincipal.java:41) > at > org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1008) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1080) > > I doubt this is an actual DNS issue, given that this works just fine on > Java 11. But there seems to be something different about the way Java 17 > handles resolution when connecting to sockets. > > Any clues? I'm running the Adoptium JDK 17 build on Linux x86_64, though > I suspect this will happen on all 17 builds. > > There is course a chance that this isn't the root cause at all, and that > this is just the side effect of some other incompatibility somewhere. > > The line numbers in the stack trace are probably off, had to fiddle > about with it to get at the stack trace. > > Thanks, > > - Bram
