Did anyone reply to this? I see a few uses of 'tc.node-name" in the code base:
- RequestCountTest.java and RogueClientTestApp.java look like they are setting it - the spring webflow and rife demos. - Some of the error messages in StatisticsGathererSubSystem and StatisticsGathererSubSystem seem to make reference to it - The session configurator use you describe I have no idea if it is being used for the same purpose in all places. To make matters worse, I think we have a property called "tc.nodeName" in the maven plugin which is probably something completely different :-) Definitely feel like some things might need to be cleaned up here _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Keim Sent: Friday, April 18, 2008 2:47 PM To: [email protected] Subject: [tc-dev] tc.node-name Does anyone understand why the JVM system property tc.node-name is being used in the codebase? I originally used it in the Session Configurator startup scripts as a way to tag a JVM as taking part in a Configurator session. But somehow it got used as a way to change the JMX object name for the L1Info bean, replacing the DSO Channel's remote address. Without setting tc.node-name the L1Info bean's name contains: Node=client.host/2361 But with it set to "Tomcat-9081" it becomes Node=Tomcat-9081 This is problematic as the L1Info bean is tunneled into the server and we need a consistent way to discover it. Tc.node-name is screwing that up. I can't find anywhere in the code where this property is actually used.
_______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
