Kafka producer: ip addresses and host names


  • Kafka client 2.4.0
  • Java 1.8.0_151
  • Kafka cluster is running on a machine with hostname ‘ubuntu-confluent’
  • Producer has bootstrap.servers=10.0.0.x (ip of same host as ubuntu-confluent)
  • At runtime, it appears hosthame is passed back to client
  • Subsequent network calls from client back to cluster appear to use hostname instead of ip, and it fails

Exception on client:

2020-03-08 21:26:06,144 [kafka-producer-network-thread | producer-1] WARN org.apache.kafka.clients.NetworkClient [] - [Producer clientId=producer-1] Error connecting to node ubuntu-confluent:9092 (id: 0 rack: null)
java.net.UnknownHostException: ubuntu-confluent: nodename nor servname provided, or not known
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) ~[?:1.8.0_151]
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928) ~[?:1.8.0_151]
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323) ~[?:1.8.0_151]
at java.net.InetAddress.getAllByName0(InetAddress.java:1276) ~[?:1.8.0_151]
at java.net.InetAddress.getAllByName(InetAddress.java:1192) ~[?:1.8.0_151]
at java.net.InetAddress.getAllByName(InetAddress.java:1126) ~[?:1.8.0_151]
at org.apache.kafka.clients.ClientUtils.resolve(ClientUtils.java:104) ~[kafka-clients-2.4.0.jar:?]

Easiest fix is to just add an entry to /etc/hosts.

What happened to the proliferation of Java web frameworks from the early 2000s?

Back in the early 2000s if you were a Java developer working on building web apps, chances are you were using Apache Struts. It was the de facto, go-to web framework of it’s time, pretty much used everywhere by everyone (it was even noticeable online for it’s pattern of using ‘*.do’ URLs for its Actions). However, it wasn’t the only framework in town. Around early to mid 2000s there was an explosion of Java based web frameworks being developed, for a while it seems like it was the-thing-to-do to build your own web framework because after all, you know better than all the other guys right?

Joking aside, other major frameworks that appeared, some of the other big names were Wicket, Cocoon, Tapestry, Webwork (Webwork and Struts merged to form Struts 2), GWT and Vaadin. In the Java EE space the standard web framework became JSF but never really gained traction over any of the others. The one that stayed the course and probably the only one still in serious usage would be Spring Web MVC.

The funny thing about all this churn that occurred is that it feels like it’s all happening again, but now in the Javascript space. Sure, once we realized we could could offload some of this backend rendering of the UI to the frontend and after Google had shown the way with GMail showing us how the user experience of a single page app is far better than the traditional request/response of web apps we had become used to, it was inevitable that serverside based Java web frameworks would fall out of favor and get replaced by Javascript clientside frameworks. Was it inevitable that the industry would go through the same learning pains once again though? I’m not sure, but it happened.

At one point jQuery was the de facto JavaScript framework, much like Struts was in the Java space back in it’s time. Then came the flood: backbone, ember, Dojo, Knockout seemed to to be the main players, eventually settling down to ‘the big 3’ that we have today, Angular, React and Vue.

So what happened to all the Java web frameworks? Spring Web MVC is still around and still in use. With the change in technologies and a shift in focus from backend web frameworks to frontend, the backend web frameworks became less relevant. Could this shift happen again? Sure, when the next big things comes along.

Moral of the story: tech changes quick in software development. Keep an eye out for whats coming next, because what’s hot today can quickly become irrelevant tomorrow.

Additional reading: if you’re interested to read more about Java web frameworks, Zeroturnaround’s Rebel Labs used to do a survey on framework usage, and you can see their findings from their relatively recent reports, from 2014, 2015 and 2017:




Revisiting my spotviz.info webapp: visualizing WSJT-X FT8 spots over time – part 4: It’s back, it’s alive! http://www.spotviz.info

I still have some refactoring to do as I move the app to the cloud, but as the first starting point I have the original app up and running on WildFly on a VPS. It’s back up and live on the original domain, http://www.spotviz.info

The uploader has been updated to read current 2.x WSJT-X log files, but I haven’t uploaded the .jar to GitLab yet, but I’ll do that soon. I’ve some test log data uploaded under my callsign, KK6DCT.

More changes to come soon.

If you’re catching up, here’s my previous posts on getting the project up and running again:

Revisiting my spotviz.info webapp: visualizing WSJT-X FT8 spots over time – part 3: Successful deployment: visualizing 20m spots from 9am to 10pm

I’ve successfully deployed my SpotViz app on WildFly running locally and tested running a visualization playback of FT8 signals received during a whole day, from 9am to 10pm. It’s interesting to see the propagation move from my location on the US West coast out to the East coast, and then gradually move West during the day, following the sun, until the propagation dies out on 20m completely around 10pm.

Here’s a screen capture of the playback:

Next up, I’ll be setting this up hosted on a VPS somewhere, and start working on some of the bugs in the UI.