I have been running Docker on OS X for quite a while now and the I switched to Docker Machine for Mac Beta few months back. It has been a great experience so far, but not without occasional hiccups. I run some of my containers in host networking mode, and I have faced the following problem when I start some of my containers.
java.net.UnknownHostException: moby: moby: Name or service not known
at java.net.InetAddress.getLocalHost(InetAddress.java:1505) ~[na:1.8.0_102]
at com.netflix.eureka.transport.JerseyReplicationClient.createReplicationClient(JerseyReplicationClient.java:170) ~[eureka-core-1.4.9.jar!/:1.4.9]
at com.netflix.eureka.cluster.PeerEurekaNodes.createPeerEurekaNode(PeerEurekaNodes.java:194) [eureka-core-1.4.9.jar!/:1.4.9]
Caused by: java.net.UnknownHostException: moby: Name or service not known
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) ~[na:1.8.0_102]
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928) ~[na:1.8.0_102]
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323) ~[na:1.8.0_102]
at java.net.InetAddress.getLocalHost(InetAddress.java:1500) ~[na:1.8.0_102]
... 67 common frames omitted
‘Moby’ is the name given to the host system that runs behind the scenes with Docker Machine for Mac (and Windows). Docker Machine for Mac runs MobyLinux VM, and the hostname file refers to itself as ‘moby’. But this entry is missing in the /etc/hosts file and my services fail to start up because it cannot resolve ‘moby’ to an IP. The workaround is simple. Just add the ‘add-host’ flag to your Docker run command telling it that ‘moby’ is ‘127.0.0.1’, like so:
docker run --net=host --add-host=moby:127.0.0.1 yourid/yourimage
This will automatically add an entry to the /etc/hosts file saying that moby in fact is 127.0.0.1.
This is going to be a short post on one of the issues I came across when I was trying to use LinkedIn DustJS on my Mac Book. I was trying out DustJS for one of the new projects I’m working on, and I came across ‘DusterJS’ (https://github.com/dmix/dusterjs/), which is a watcher that could monitor your .dust files and convert them on-the-fly to compiled dust templates. This is a life saver when it comes to developing dust templates, and kudos to the author for writing such a great tool.
This is a presentation that I did recently for my team, on Zhara POS (which is the Point of Sale module of Zhara Hospitality Suite, the product that I’m working on at JKCS). We developed the application using Swing, and deployed it over the web via Java Web Start.
The presentation discusses the rationale for using Java Web Start, and how we applied it to meet with the requirements.
The audience of the presentation was the entire Zhara Team, which consists of designers, developers, QA, business analysts working on many modules.
This presentation was part of the Zhara Tech Talks Series (session 03), which is held bi-weekly, where the team meets up and discuss about various topics of interest, both technical and non-technical.
Logging is a mechanism of keeping track of the runtime behavior of an application, mainly for debugging / tracing purposes. In almost all of significantly complex / vital applications, maintaining a proper application log is a must; hence, almost all developers are quite familiar with the paradigm of logging. And it isn’t rocket science. You just have to call a simple method with whatever you want to log, and mess around with a simple configuration file, and that’s all. So what’s the big deal?
The problem is that though logging is a simple thing to do, doing it correctly needs a lot of practice, experience and understanding. That makes it more of an art than a science. In my personal experience, mastering the art of logging requires lots of patience, experience and forward thinking. It’s quite difficult to teach someone how to do it (sort of tacit knowledge), and most freshers tend to see the effort put into writing to log files as something additional. But all that effort pays up when you go through long nights trying to figure out what went wrong in a production system. But for that, it is important that proper logging is done through-out the system, which requires all of the team to master this dark art. Just one guy doing it right in a team is simply not enough.
How many times have we created various object instances, and assign those to reference variables? We all know very well that Java has automatic garbage collection; so we just play around the reference variables, and once those variables are assigned null or falls out of scope, JVM takes care of it. No need to worry about ‘free’ as in C / C++. It’s a headache-less approach, which minimizes the risk of introducing memory leaks to our programs, and it works out great day in day out in billions of Java applications running out there 24×7. Kudos to John McCarthy for inventing GC for Lisp, and to all the folks who implemented the concept in Java.
But there are times, where we a little bit of more control over the process of garbage collection. I’m not talking about the dark art of tuning the garbage collector (which I might cover in a later article). This is about programmatic situations where we expect some object instances to be eligible for garbage collection, to release some unwanted memory that might get accumulated over the time. Well, the classic solution of explicitly assigning null could help us out; given that particular object is referred only through that particular ref variable. What if assigning null doesn’t work out for the problem at hand?