• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • Configuration,Documentation
  • kkannaiy
  • Reporter: benze
  • September 17, 2009
  • 0
  • Watchers: 1
  • February 12, 2013
  • November 20, 2009

Description

Hi,

According to the Configuration Guide and Reference, the following config values can be used in client/server logs and data locations: %h The hostname %i The ip address

However, when I use %h or %i, they both resolve to the same thing - the IP address of my host.

For example:

/var/lib/terracotta/%h/data /var/log/terracotta/%h /var/lib/terracotta/%h/statistics 9530

The directory that TC creates for me is /var/lib/terracotta/10.1.1.4/data, which is the IP address for my machine (10.1.1.4). ‘hostname’ at the prompt properly displays my host as being linus.domain.com.

I’m using TC 3.1GA. Is this a bug in TC, or am I using the vars incorrectly? I was hoping for /var/lib/terracotta/linus/data

Thanks,

Eric

Comments

Tim Eck 2009-09-17

%h should expand the way you want. I don’t know what is going wrong, but I suspect it isn’t related to terracotta.

The code that implements that function is here: http://svn.terracotta.org/svn/tc/dso/tags/3.1.0/code/base/common-api/src/com/tc/config/schema/dynamic/ParameterSubstituter.java

Specifically the getHostName() method: public static String getHostname() { try { return InetAddress.getLocalHost().getCanonicalHostName(); } catch (UnknownHostException uhe) { throw new RuntimeException(uhe); } }

The javadocs for InetAddress.getLocalHost().getCanonicalHostName() say it will return the IP address if the host name cannot be resolved http://java.sun.com/j2se/1.5.0/docs/api/java/net/InetAddress.html#getCanonicalHostName%28%29

Can you run a test program that makes this same call to see if it works without Terracotta in the mix? Run this test program on the same computer where you are running terracotta obviously

Eric B 2009-09-17

Fair enough. Thanks for the quick feedback.

I took the above code and ran it as its own java program, and sure enough, that too returned the IP for my machine. A little more digging around on the getCannonicalHostName() method pointed me to a Sun site which explains that Java uses a reverse dns lookup to find the hostname.

I changed my DNS server settings to point to my internal DNS server, and sure enuf, the app now returns my machine’s FQDN instead of the address.

You may want to update the documentation to elaborate how the hostname is resolved.

The following Sun site helped me resolve the issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4773521

Tim Eck 2009-09-17

thanks for running that test. I’ll look at our code again, perhaps we shouldn’t be using a method that relies on reverse lookup to properly setup (since it often isn’t)

Chris Dennis 2009-11-16

Looks to me like we should be doing:

InetAddress.getLocalHost.getHostName()

This will attempt to return the hostName the address was created with before attempting a reverse lookup. getCanonicalHostName goes straight to the reverse lookup.

Tim Eck 2009-11-16

looks like could work better. I seem to recall that code getting changed to canonical host name to “fix” things in other cases (might want to search svn/bk history on this).

It might be extreme, but in the event that we’re going to return a textual IP for %h we might throw an exception instead? Might just cause more headaches than it solves :-)

Chris Dennis 2009-11-18

The getCanonicalHostName call seems to date back to before the beginning of the bitkeeper repo. So if there is a good reason for using it, it is lost in the mists of time. The only thing that worries me about changing this is that it could break peoples automated scripts (including our own monkeys?) if things suddenly start getting spat out to a different directory.

Eric B 2009-11-19

Changes from TC3.0 to TC3.1 were significant enough that it required rebuilds of several different things, including our own scripts, config files, etc. I would expect that customers would be willing to retest their setups when making a big switch such as that.

That being said, if you are concerened about backwards compatibility, perhaps keep %h for getCannonicalHostName() (but mark it as deprecated) and use %H for InetAddress.getLocalHost.getHostName().

This allows users to use the safer option without the risk of breaking older things. And in a later version, eventually discontinue the %h option.

Chris Dennis 2009-11-20

Changed %h to use getHostName, and added %c for getCanonicalHostName()

Kalai Kannaiyan 2009-12-08

Verified with 3.2 rev14155 on my windows box, %h created the hostname as KKANNAPC %i created the ip address as 10.0.0.173 %c created as KKANNAPC.terracotta.lan.