logo       

Uses of system property substitution in JGroups: msg#00001

java.javagroups.general

Subject: Uses of system property substitution in JGroups

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>
Google Custom Search

News | FAQ | advertise