JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF

The open source
grid computing
solution

 Home   About   Features   Download   Documentation   On Github   Forums 

Common configuration properties

From JPPF 6.2 Documentation

Jump to: navigation, search

Contents

Main Page > Configuration guide > Common configuration properties


1 Lookup of classpath resources in the file system

By default, the JPPF distributed class loader looks for requested resources in the file system (using the resource name as file path), if they are not found in the class path. This behavior can be disabled by setting the following property in a node, server or client:

# Enable or disable the lookup of classpath resources in the file system
jppf.classloader.file.lookup = true

Since this property applies to the lookup of remote resources, the file system lookup will occur if and only if this property is true in the node configuration and in the server or client configuration. Also note that its value is true by default.

2 Socket connections recovery and failover

When the connection to a server is interrupted, the node, client or peer servr will automatically attempt, for a given length of time, and at regular intervals, to reconnect to the same server. These properties are configured as follows, with their default values:

# number of seconds before the first reconnection attempt
jppf.reconnect.initial.delay = 0

# time after which the system stops trying to reconnect, in seconds
# a value of zero or less means it never stops
jppf.reconnect.max.time = 60

# time between two connection attempts, in seconds
jppf.reconnect.interval = 1

With these values, we have configured the recovery mechanism such that it will attempt to reconnect to the server after a 0 second delay, for 60 seconds and with connection attemps at 1 second intervals.

3 JMX requests timeout

In some very rare cases, a JMX request may be stuck because an error occurrred in the remote driver or node, without breaking the JMX connection. A typical example is when an OutOfMemoryError occurs while the remote peer is executing the request. To avoid this, it is possible to set JMX request timeout withi this configuration property:

# Timeout in millis for JMX requests. Defaults to Long.MAX_VALUE (2^63 - 1)
jppf.jmx.request.timeout = $script{ java.lang.Long.MAX_VALUE }$

4 Global performance tuning parameters

These configuration properties affect the performance and throughput of I/O operations in JPPF. The values provided in the vanilla JPPF distribution (listed below) are known to offer a good performance in most situations and environments. These properties are defined as follows:

# Size of send and receive buffer for socket connections
# Defaults to 32768 and must be in range [1024, 1024*1024]
jppf.socket.buffer.size = 65536

# Size of temporary buffers (including direct buffers) used in I/O transfers
# Defaults to 32768 and must be in range [1024, 1024*1024]
jppf.temp.buffer.size = 12288

# Maximum size of temporary buffers pool (excluding direct buffers). When this size
# is reached, new buffers are still created, but not released into the pool, so they
# can be quickly garbage-collected.
# The size of each buffer is defined with ${jppf.temp.buffer.size}
# Defaults to 10 and must be in range [1, 2048]
jppf.temp.buffer.pool.size = 200

# Size of temporary buffer pool for reading lengths as ints (size of each buffer is 4)
# Defaults to 100 and must be in range [1, 2048]
jppf.length.buffer.pool.size = 100
Main Page > Configuration guide > Common configuration properties



JPPF Copyright © 2005-2020 JPPF.org Powered by MediaWiki