CDV ❯ Usability issue w/ tag in tc-config.xml
-
Bug
-
Status: Closed
-
3 Minor
-
Resolution: Fixed
-
DSO:L1,DSO:L2
-
-
qa
-
Reporter: ari
-
November 14, 2006
-
0
-
Watchers: 0
-
February 12, 2013
-
March 08, 2007
Description
When I tried to run clients on different hosts (for my Virgina and NYC JUG) I ran into lots of frustration getting the client L1 to connect across a network to the L2. After lots of frustration, I uncovered that the following won’t work (in the case of no DNS):
Server name should support both computer host name and numerical IP address.
I’ve debugged this a little. The current logic sets host value to the local IP address. See com.tc.config.schema.setup.StandardXMLFileConfigurationCreator.java (line 331)
After that logic for using name as a host in com.tc.config.schema.L2ConfigForL1Object.java (line 57) never work, because host value is never nur or empty at this point.
So, the current behaviour is actually like this: if host is not specified, localhost is assumed in this case. Which is probably make some sense, but need to be fixed in the documentation.
Please let me know if we should change that to use name value for the host as per current documentation.
I’m a bit confused. So is ari wrong about what the problem was? Can someone put either an ip address or a hostname in that field?
There is no difference in treating name or the host attribute. However, if host is not specified it is always defaulted to the local ip address and not to the value of name attribute.
Ari was following to what documentation is saying, but apparently documentation is not correct.
I’m still waiting for a reply on tc-dev as to what this thing really does, but the best I’ve heard so far informally is that this tag is used to identify the server in the admin console. Additionally, if you have multiple servers using the same configuration file you can identify exactly which one to start/stop/etc.
It seems to me that if this attribute is causing problems (as it appears to be from a real user in a JUG) we should just get rid of it as it’s really not necessary, at least any more. The conceivable use case of having multiple L2 servers on one or more machines using the exact same configuration file seems like a < %1 case, whereas > 99% of users will never do this.
I think most people would, however, like to see the ability to “name” an L2 for use in the admin console, reporting, monitoring, etc., but I believe we already have a -n switch in start-tc-server.sh that could just as easy provide a user-defined name instead of
Just my two cents.
I guess I misinterpreted the description in my last comment: I thought this was an issue from a user trying our software who was a member of two JUGs. I think I still have a fair point, though :)
Per the dev list (and Steve) the “name” attribute will be renamed to “alias” to make it clear that this is not where the hostname/IP address goes but is only a symbolic name.
The description is the result of a bug in which the code does not behave how the documentation (the schema itself) says it does. It claims that the value for the “host” attribute defaults to the value of the “name” attribute which simply wasn’t true (until revision 1686). By putting the IP address in the “name” attribute it would not propagate to the “host” element as the docs suggest and would instead default to the local machine IP address which was, of course, wrong and cause the situation Ari saw.
IP addressing and DNS naming have always worked, and with this fix the “name” will now propertly be the default value for “host” if “host” is not given, so the situation in the description should now work.
If this is something you can fix easily than squeeze it in. If not we’ll move it out to moraga since we are down to the wire.