|
Uses of system property substitution in JGroups: msg#00001java.javagroups.general
Bela's recently add JBoss-style system property resolution to the code that parses protocol stack configs (see http://jira.jboss.com/jira/browse/JGRP-272). I'm opening this thread to get feedback from people on what config elements would be useful to externalize via system properties. BACKGROUND For those unfamiliar with JBoss-style system property resolution, basically an attribute in the protocol stack config would be specified like this: <UDP mcast_addr="${jboss.partition.udpGroup:230.1.2.7}" ... The parser when it sees the that syntax looks for system property jboss.partition.udpGroup and if found assigns that property's value to the attribute. If no such property is found, the default value 230.1.2.7 is used. The advantage is this technique lets admins externalize setting the config values out of hidden config files into the script that starts java. Very useful as apps move from dev to QA to production. QUESTION We'd like to get feedback from the community as to what config attributes it makes sense to replace by default with system properties. That is, in the config files that ship with JGroups (and also JBoss AS and JBoss Cache), what attributes should have system properties, and what should the names be? (Please note that you can make up and use whatever system property you want for any attribute; this is just a discussion of useful standard ones to include with our distributions.) What we have discussed so far: UDP.mcast_addr --> jboss.partition.udpGroup (as I write I've come to prefer jboss.udp.mcast.addr) UDP.mcast_port --> jboss.partition.udpPort (as I write this I've come to prefer jboss.udp.mcast.port) UDP.ip_ttl --> jboss.mcast.ip.ttl (here we're considering a default of 2 to prevent multicast leaking across routers. Comments?) TCPPING.initial_hosts --> jboss.tcpping.initial.hosts A couple others that come to mind are: MPING.mcast_addr --> jboss.mping.mcast.addr MCAST.mcast_port --> jboss.mping.mcast.port MCAST.ip_ttl --> jboss.mcast.ip.ttl (same as UDP) A seemingly obvious one is the various uses of bind_addr. But, internally JGroups already looks for system property bind.address when setting that attribute. So, adding it to a config file a la <UDP bind_addr="${bind.address:localhost}" ... /> would just be making explicit in a config file an existing behavior. And the downside is if the bind.address system property isn't set, JGroups will use the default "localhost". On my XP machine at least, the default hosts file maps localhost to 127.0.0.1, which likely isn't the desired interface. Thoughts? Cheers, Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
|
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: UNICAST problem when a node is disconnected/reconnected to network (issue for 2.4), Bela Ban |
|---|---|
| Next by Date: | Re: bind_addr different from mcast_recv_sock and mcast_send_sock, Bela Ban |
| Previous by Thread: | Re: UNICAST problem when a node is disconnected/reconnected to network (issue for 2.4), Bela Ban |
| Next by Thread: | Re: bind_addr different from mcast_recv_sock and mcast_send_sock, Bela Ban |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |