Client and administration console configuration
From JPPF 3.3 Documentation
|
Main Page > Configuration guide > Client and administration console |
1 Server discovery
By default, JPPF clients are configured to automatically discover active servers on the network. This mechanism works in the same way as for the nodes, and uses the same configuration properties, except for the discovery timeout:
# Enable or disable automatic discovery of JPPF drivers jppf.discovery.enabled = true # UDP multicast group to which drivers broadcast their connection parameters jppf.discovery.group = 230.0.0.1 # UDP multicast port to which drivers broadcast their connection parameters jppf.discovery.port = 11111 # IPv4 address inclusion patterns jppf.discovery.include.ipv4 = # IPv4 address exclusion patterns jppf.discovery.exclude.ipv4 = # IPv6 address inclusion patterns jppf.discovery.include.ipv6 = # IPv6 address exclusion patterns jppf.discovery.exclude.ipv6 =
A major difference is that, when discovery is enabled, the client does not stop attempting to find one or more servers. A client can also connect to multiple servers, and will effectively connect to every server it discovers on the network.
A client can also create mutliple connections to each discovered server, effectively creating a connection pool that can be used for concurrent job submissions. The size of the connection pools is configured with the following property:
# connection pool size for each discovered server; defaults to 1 (single connection)
jppf.pool.size = 5
Each server connection has an assigned name, following the pattern: “driver-<n>[-]”, where n is a driver number, in order of discovery, and the optional p is the connection number, if the defined connection pool size is greater than 1. For instance:
- if we defined jppf.pool.size = 1, the first discovered driver will have 1 connection named “driver-1”
- if we defined jppf.pool.size = 2, the first discovered driver will have 2 connections named “driver-1-1” and “driver-1-2”
2 Manual network configuration
As we have seen, a JPPF client can connect to multiple drivers. The first step will this be to name these drivers:
# space-separated list of drivers this client may connect to # defaults to “default-driver” jppf.drivers = driver-1 driver-2
Then for each driver, we will define the connection and behavior attributes, including:
Connection to the JPPF server
# host name, or ip address, of the host the JPPF driver is running on driver-1.jppf.server.host = localhost # port number the server is listening to for connections driver-1.jppf.server.port = 11111
Here, driver-1.jppf.server.port must have the same value as the corresponding property jppf.server.port defined in the server configuration.
Backward compatibility with JPPF v2.x: To avoid too much disruption in applications configured for JPPF v2.x, JPPF will use the server port defined with the "old" property "driver-1.class.server.port" if "driver-1.jppf.server.port" is not defined.
Connection pool size
# size of the pool of connections to this driver
driver-1.jppf.pool.size = 5
This allows the creation of a connection pool with a specific size for each server we connect to, whereas all pools would have the same size when server discovery is enabled.
Priority
# assigned driver priority
driver-1.priority = 10
The priority assigned to a server connection enables the defintion of a fallback strategy for the client. In effect, the client will always use connections that have the highest priority. If the connection with the server is interrupted, then the client we use connections with the next highest priority in the remaining accessible server connection pools.
Note: the failover based on connection priority will only work if used in conjunction with the ClientWithFailover API. See the section The ClientWithFailover wrapper class for details.
Connection to the management server
# management host for this driver driver-1.jppf.management.host = localhost # management port for this driver driver-1.jppf.management.port = 11198
This will allow direct access to the driver's JMX server using the client APIs, unless the client configuration property jppf.management.enabled is set to false.
3 Using manual configuration and server discovery together
It is also possible to use the manual server configuration simultaneously with the server discovery, by adding a specific driver name, “jppf_discovery” to the list of manually configured drivers:
# enable discovery jppf.discovery.enabled = true # specifiy both discovery and manually configured drivers jppf.drivers = jppf_discovery driver-1 # host for this driver driver-1.jppf.server.host = my_host # port for this driver driver-1.jppf.server.port = 11111
4 Recovery and failover
As for the nodes, when the connection to a server is interrupted, the client will automatically attempt to reconnect to the same server. This is configured as follows, with the default values:
# number of seconds before the first reconnection attempt reconnect.initial.delay = 1 # time after which the system stops trying to reconnect, in seconds # a value of zero or less means it never stops reconnect.max.time = 60 # time between two connection attempts, in seconds reconnect.interval = 1
With these values, we have configured the recovery mechanism such that it will attempt to reconnect to the server after a 1 second delay, for 60 seconds and with connection attemps at 1 second intervals.
5 Socket connections idle timeout
In some environments, a firewall may be configured to automatically close socket connections that have been idle for more than a specified time. This may lead to a situation where a server may be unaware that a client was disconnected, and cause one or more jobs to never return. To remedy to that situation, it is possible to configure an idle timeout on the client side of the connection, so that the connection can be closed cleanly and grid operations can continue unhindered. This is done via the following property:
jppf.socket.max-idle = timeout_in_seconds
If the timeout value is less than 10 seconds, then it is considered as no timeout. The default value is -1.
6 Local and remote execution
It is possible for a client to execute jobs locally (i.e. in the client JVM) rather than by submitting them to a server. This feature allows taking advantage of muliple CPUs or cores on the client machine, while using the exact same APIs as for a distributed remote execution. I can also be used for local testing and debugging before performing the “real-life” execution of a job.
Local execution is disabled by default. To enable it, set the following configuration property:
# enable local job execution; defaults to false
jppf.local.execution.enabled = true
Local execution uses a pool of threads, whose size is configured as follows:
# number of threads to use for local execution # the default value is the number of CPUs or cores available to the JVM jppf.local.execution.threads = 4
It is also possible to mix local and remote execution. This will happen whenever the client is connected to a server and has local execution enabled. In this case, the JPPF client uses an adaptive load-balancing algorithm to balance the workload between local execution and node-side execution.
Finally, the JPPF client also provides the ability to disable remote execution. This can be useful if you want to test the execution of jobs purely locally, even if the server discovery is enabled or the server connection properties would otherwise point to a live JPPF server. To achieve this, simply configure the following:
# enable remote job execution; defaults to true
jppf.remote.execution.enabled = false
7 Local execution flow
You can specify how frequently you wish to receive notfiications of locally executed tasks, using either or both of the following parameters:
# specifies for how many completed tasks to wait until a notification is sent jppf.local.execution.accumulation.size = 4 # specifies how long to wait before a notification is sent # (if any task has completed) jppf.local.execution.accumulation.time = 100 # specifies the time unit: # n = nanoseconds M = minutes # m = milliseconds h = hours # s = seconds d = days jppf.local.execution.accumulation.unit = m
If both accumulation time and size are used at the same time, a notification will be sent whenever the size is reached, or the time is reached, whichever happens first. If neither is specified, the tasks wil be returned all at once.
8 Load-balancing in the client
The JPPF client allows load balancing between local and remote execution. The load balancing configuration is exactly the same as for the driver, which means it uses exactly the same configuration properties, algorithms, parameters, etc... Please refer to the driver load-balancing configuration section for the configuration details. The default configuration, if none is provided, is equivalent to the following:
# name of the load balancing algorithm jppf.load.balancing.algorithm = proportional # name of the set of parameter values (aka profile) to use for the algorithm jppf.load.balancing.strategy = test # "proportional" profile strategy.test.performanceCacheSize = 2000 strategy.test.proportionalityFactor = 1 strategy.test.initialSize = 10 strategy.test.initialMeanTime = 1e9
Also note that the load balancing is active even if only remote execution is available. This has an impact on how tasks within a job will be sent tot he server. For instance, if the “manual” algorithm is configured, with a size of 1, this means the tasks in a job will be sent one at a time.
9 Full client configuration file (default values)
# list of drivers this client may connect to jppf.drivers = driver-1 driver-2 # host name, or ip address, of the host the JPPF driver is running on driver-1.jppf.server.host = localhost # server port number driver-1.jppf.server.port = 11111 # priority given to the driver connection driver-1.priority = 0 # connection poool size for this driver driver-1.jppf.pool.size = 1 # host name for the management server driver-1.jppf.management.host = localhost # port number for the management server driver-1.jppf.management.port = 11198 # configuration for connection driver-2 driver-2.jppf.server.host = my.host.com driver-2.jppf.server.port = 11121 driver-2.jppf.management.port = 12003 driver-2.priority = 10 driver-2.jppf.pool.size = 1 # enable/disable automatic discovery of JPPF drivers jppf.discovery.enabled = true # UDP multicast group to which drivers broadcast their connection parameters jppf.discovery.group = 230.0.0.1 # UDP multicast port to which drivers broadcast their connection parameters jppf.discovery.port = 11111 # automatic recovery: number of seconds before the first reconnection attempt reconnect.initial.delay = 1 # time after which the system stops trying to reconnect, in seconds reconnect.max.time = 60 # automatic recovery: time between two connection attempts, in seconds reconnect.interval = 1 # enable/disable local job execution; defaults to false jppf.local.execution.enabled = false # number of threads to use for local execution jppf.local.execution.threads = 4 # specifies for how many completed tasks to wait before a notification is sent jppf.local.execution.accumulation.size = 4 # how long to wait before a notification is sent jppf.local.execution.accumulation.time = 100 # the time unit jppf.local.execution.accumulation.unit = m # name of the load balancing algorithm jppf.load.balancing.algorithm = proportional # name of the set of parameter values (aka profile) to use for the algorithm jppf.load.balancing.strategy = test # "proportional" profile strategy.test.performanceCacheSize = 2000 strategy.test.proportionalityFactor = 1 strategy.test.initialSize = 10 strategy.test.initialMeanTime = 1e9
| Main Page > Configuration guide > Client and administration console |
