A ProActive runtime is only able to bind to one and only one InetAddress. Usually, this limitation is not seen by the user and no special configuration is required. ProActive tries to use the most suitable network address available. But sometimes, the right IP address cannot be elected or the user wants to use a given IP address. In such case, you can specify the IP address to use by using theses properties: proactive.hostname, proactive.net.interface, proactive.net.netmask, proactive.net.nolocal, proactive.net.noprivate.
IPv6 can be enabled by setting the proactive.net.disableIPv6 property to false. By default ProActive will not use IPv6 addresses.
If none of the proactive.hostname, proactive.net.interface, proactive.net.netmask, proactive.net.nolocal, proactive.net.noprivate properties is defined, then the following algorithm is used to elect an IP address:
• If a public IP address is available use it. If several ones are available, one is chosen randomly.
• If a private IP address is available use it. If several ones are available, one is chosen randomly.
• If a loopback IP address is available use it. If several ones are available, one is chosen randomly.
• If no IP address is available at all. Then the runtime exits with an error message.
If proactive.hostname is set, then the value returned by InetAddress.getByName(proactive.hostname) is elected. If no IP address is found, then the runtime exits with an error message.
If proactive.hostname is not set, and at least one of the proactive.net.interface, proactive.net.netmask, proactive.net.nolocal, proactive.net.noprivate is set, then one of the addresses matching all the requirements is elected. Requirements are:
• If proactive.net.interface is set, then the IP address must be bound to the given network interface.
• If proactive.net.netmask is set, then the IP address must match the given netmask.
• If proactive.net.nolocal is set, then the IP address must not be a loopback address.
• If proactive.net.noprivate is set, then the IP address must not be a private address.
If no address matches theses criteria, the runtime exits with an error message.

“Scheduler loading” policy – acquires/releases nodes according to the scheduler load, which can be characterized for example by the number of nodes per task.
For example, if the policy is configured to “1 node per task” and if a job with 10 tasks is submitted, then 10 nodes will be dynamically acquired from the infrastructure.

This policy allows to configure the number of resources which will be always enough for the scheduler. Nodes are acquired and released according to scheduler loading factor which is a number of tasks per node. This policy requires scheduler URL, user name and password. It is important to correctly configure maximum and minimum nodes that this policy will try to hold.
Maximum number should not be greater than potential nodes number which is possible to deploy to underlying infrastructure.
If there are more currently acquired nodes than necessary, policy will release them one by one after having waited for a “release period” delay. This smooth release procedure is implemented because deployment time is greater than release one. Thus, this waiting time deters policy from spending all its time trying to deploy nodes.