| Prev | Part IV. Deploying Chapter 20. ProActive Basic Configuration |  | Next |
| Prev | Part IV. Deploying Chapter 20. ProActive Basic Configuration | | Next |
In order to get easier and more flexible configuration in ProActive, we introduced an xml file where all ProActive related configuration is located. It represents properties that will be added to the System when an application using ProActive is launched. Some well-known properties(explained after) will determine the behaviour of ProActive services inside a global application. That file can also contain user-defined properties to be used in their application.
Using this file is very straightforward, since all lines must follow the model: <prop key='somekey' value='somevalue'/>
Those properties will be set in the System using System.setProperty(key,value) if and only if this property is not already set in the System.
If an application is using ProActive, that file is loaded once when a method is called through a ProActive 'entry point'. By 'entry point' we mean ProActive class, NodeFactory class, RuntimeFactory class (static block in all that classes).
For instance calling ProActive.newActive or NodeFactory.getNode .... loads that file. This only occurs once inside a jvm.
As said before this file can contain user-defined properties. It means that people used to run their application with:
java .... -Dprop1=value1 -Dprop2=value2 .... -Dpropn=valuen can define all their properties in the ProActive configuration file with:
<prop key='prop1' value='value1'/>
<prop key='prop2' value='value2'/>
...
<prop key='propn' value='valuen'/>
There is a default file with default ProActive options located under ProActive/src/org/objectweb/proactive/core/config/ProActiveConfiguration.xml. This file is automatically copied with the same package structure under the classes directory when compiling source files with the ProActive/compile/build facility. Hence it is included in the jar file of the distribution under org/objectweb/proactive/core/config/ProActiveConfiguration.xml (See below for default options).
People can specify their own configuration file by running their application with proactive.configuration option, i.e
java ... -Dproactive.configuration=pathToTheConfigFile. In that case, the given xml file is loaded. Some ProActive properties(defined below) are required for applications using ProActive to work, so even if not defined in user config file, they will be loaded programatically with default values. So people can just ignore the config file if they are happy with the default configuration or create their own file if they want to change ProActive properties values or add their own properties
A specific tag: <ProActiveUserPropertiesFile> is provided in Deployment Descriptors (see Chapter 21, XML Deployment Descriptors) to notify remote jvms which configuration file to load once created:
<jvmProcess class='org.objectweb.proactive.core.process.JVMNodeProcesss'> ... <ProActiveUserPropertiesFile> <absolutePath value='/net/home/rquilici/config.xml'/> </ProActiveUserPropertiesFile> ... </jvmProcess>
proactive.communication.protocol represents the communication protocol i.e the protocol, objects on remote JVMS are exported with. At this stage several protocols are supported: RMI(rmi), HTTP(http), IBIS/RMI(ibis), SSH tunneling for RMI/HTTP(rmissh), JINI(jini). It means that once the JVM starts, Nodes, Active Objects that will be created on this JVM, will export themselves using the protocol specified in proactive.communication.protocol property. They will be reachable transparently through the given protocol.
schema.validation . Two values are possible:enable, disable. If enable, all xml files will be validated against provided schema. Default is disable
proactive.future.ac . Two values are possible:enable, disable If 'enable' is chosen, Automatic Continuations are activated (see Section 13.9, “Automatic Continuation in ProActive”). Default is enable
Note that if not specified those properties are set programmatically with the default value.
Note that those properties should not be altered if the programmer uses deployment descriptor files. See Chapter 25, Fault-Tolerance and more specifically Section 25.2.3, “Configure fault-tolerance for a ProActive application” for more details.
proactive.ft . Two values are possible: enable, disable. If enable, the fault-tolerance is enable and a set of servers must be defined with the following properties. Default value is disable.
proactive.ft.server.checkpoint is the URL of the checkpoint server.
proactive.ft.server.location is the URL of the location server.
proactive.ft.server.recovery is the URL of the recovery process .
proactive.ft.server.resource is the URL of the resource server.
proactive.ft.server.global is the URL of the global server. If this property is set, all others proactive.fr.server.* are ignored.
proactive.ft.ttc is the value of the Time To Checkpoint counter, in seconds. The default value is 30 sec.
proactive.p2p.acq is the communication protocol that's used to communicate with this P2P Service. All ProActive communication protocols are supported: rmi, http, etc. Default is rmi.
proactive.p2p.port represents the port number on which to start the P2P Service. Default is 2410. The port is used by the communication protocol.
proactive.p2p.noa: Number Of Acquaintances (NOA) is the minimal number of peers one peer needs to know to keep up the infrastructure. By default, its value is 10 peers.
proactive.p2p.ttu: Time To Update (TTU) each peer sends an heart beat to its acquaintances. By default, its value is 1 minutes.
proactive.p2p.ttl: Time To Live (TTL) represents messages live time in hops of JVMs (node). By default, its value is 5 hops.
proactive.p2p.msg_capacity is the maximum memory size to stock message UUID. Default value is 1000 messages UUID.
proactive.p2p.expl_msg is the percentage of agree response when peer is looking for acquaintances. By default, its value is 66%.
proactive.p2p.booking_max uses during booking a shared node. It's the maximum time in millisecond to create at less an active object in the shared node. After this time and if no active objects are created the shared node will leave and the peer which gets this shared node will be not enable to use it more. Default is 3 minutes.
proactive.p2p.nodes_acq_to uses with descriptor file. It is the timeout in milliseconds for nodes acquisition. The default value is 3 minutes.
proactive.p2p.lookup_freq also uses with descriptor file. It is the lookup frequency in milliseconds for re-asking nodes. By default, it's value is 30 seconds.
proactive.p2p.multi_proc_nodes if true deploying one shared nodes by CPU that means the p2p service which is running on a bi-pro will share 2 nodes, else only one node is shared independently of the number of CPU. By default, it's value is true, i.e. 1 shared node for 1 CPU.
proactive.p2p.xml_path is the XML deployment descriptor file path for sharing nodes more than a single node.
The following properties are specific to the rmissh protocol (see Chapter 24, Using SSH tunneling for RMI or HTTP communications).
proactive.ssh.port: the port number on which all the ssh daemons to which this JVM must connect to are expected to listen. If this property is not set, the default is 22.
proactive.ssh.username: the username which will be used during authentication with all the ssh daemons to which this JVM will need to connect to. If this property is not set, the default is the user.name java property.
proactive.ssh.known_hosts: a filename which identifies the file which contains the traditional ssh known_hosts list. This list of hosts is used during authentication with each ssh daemon to which this JVM will need to connect to. If the host key does not match the one stored in this file, the authentication will fail. If this property is not set, the default is System.getProperty ('user.home') + '/.ssh/known_hosts'
proactive.ssh.key_directory: a directory which is expected to contain the pairs of public/private keys used during authentication. the private keys must not be encrypted. The public keys filenames must match '*.pub'. Private keys are ignored if their associated public key is not present. If this property is not set, the default is System.getProperty ('user.home') + '/.ssh/'
proactive.tunneling.try_normal_first: if this property is set to 'yes', the tunneling code always attempts to make a direct rmi connection to the remote object before tunneling. If this property is not set, the default is not to make these direct-connection attempts. This property is especially useful if you want to deploy a number of objects on a LAN where only one of the hosts needs to run with the rmissh protocol to allow hosts outside the LAN to connect to this frontend host. The other hosts located on the LAN can use the try_normal_first property to avoid using tunneling to make requests to the LAN frontend.
proactive.tunneling.connect_timeout: this property specifies how long the tunneling code will wait while trying to establish a connection to a remote host before declaring that the connection failed. If this property is not set, the default value is 2000ms.
proactive.tunneling.use_gc: if this property is set to 'yes', the client JVM does not destroy the ssh tunnels are soon as they are not used anymore. They are queued into a list of unused tunnels which can be reused. If this property is not set or is set to another value, the tunnels are destroyed as soon as they are not needed anymore by the JVM.
proactive.tunneling.gc_period: this property specifies how long the tunnel garbage collector will wait before destroying a unused tunnel. If a tunnel is older than this value, it is automatically destroyed. If this property is not set, the default value is 10000ms.
proactive.rmi.port represents the port number on which to start the RMIRegistry. Default is 1099. If an RMIRegistry is already running on the given port, jms use the existing registry
proactive.http.port represents the port number on which to start the HTTP server. Default is 2010. If this port is occupied by another application, the http server starts on the first free port(given port is incremented transparently)
proactive.useIPaddress if set to true, IP adresses will be used instead of machines names. This property is particularly usefull to deal with sites that do not host a DNS
proactive.hostname when this property is set, the host name on which the jvm is started is given by the value of the property. This property is particularly usefull to deal with machines with two network interfaces
proactive.locationserver represents the location server class to instantiate when using Active Objects with Location Server
proactive.locationserver.rmi represents the url under which the Location Server is registered in the RMIRegistry
fractal.provider This property defines the bootstrap component for the Fractal component model
proactive.classloader runtimes created with this property enabled fetch missing classes using a special mechanism (see the classloader package javadoc ). This is an alternative to RMI dynamic class downloading, useful for instance when performing hierarchical deployment.
Note that as mentionned above, user-defined properties can be added.
A configuration file could have following structure:
<ProActiveUserProperties> <properties> <prop key='schema.validation' value='disable'/> <prop key='proactive.future.ac' value='enable'/> <prop key='proactive.communication.protocol' value='rmi'/> <prop key='proactive.rmi.port' value='2001-2005'/> .... <prop key='myprop' value='myvalue'/> .... </properties> </ProActiveUserProperties>
Example 20.1. A configuration file example
![[Note]](images/note.png) | Note |
|---|---|
In order to have ProActive parse correctly the document, the following are mandatory:
|
© 2001-2007 INRIA Sophia Antipolis All Rights Reserved