Overview
System properties are Java virtual machine level options that allow you to configure advanced pulse™ variables. They serve a similar purpose to environment variables at the operating system level.
Setting System Properties
There are multiple ways to set system properties, depending on how you launch pulse™ and whether you want the properties to persist.
system.properties
The easiest way to set a property that will persist for all invocations of pulse™ is to use the file:
where $PULSE_DATA is the location of the data directory. You may need to create the file if it does not exist. The file uses the standard Java property file format, with properties specified as <key>=<value> pairs, one per line. Special characters such as backslashes must be escaped with a backslash.
This file is loaded at startup time. If you make an edit to the file while pulse™ is running, it will not take effect until you restart pulse™.
JAVA_OPTS
If you run pulse™ using the pulse start command (see Server Commands), you can specify JVM options using the environment variable JAVA_OPTS. By default, this variable has the following value:
This value configures the JVM to allow pulse™ to use up to 512MB of memory. You can add system properties to this value in the form -D<key>=<value>, for example:
Properties set in this way only last for the invocation of pulse™. To use the properties for all invocations, you can set the environment variable at the system level, for example in the pulse user's profile.
wrapper.conf
If you are running pulse™ as a service, you can specify JVM parameters using the file:
Properties are specified using the wrapper.java.additional.<n> options, for example:
Note that properties set in this way will be used for all invocations of pulse™ as a service. However, they will not persist across upgrades.
Available Properties
Note that some server properties are only configured on the master (although they may or may not affect the agents). Properties that need to be set individually on each agent are indicated in the "Configured On" column below. There are also properties that are only configured on a developer tools installation.
| Property |
Description |
Configured On |
Default |
Example |
| pulse.agent.log.timeouts |
If set to true, timeouts when pinging agents will be recorded in the system logs. |
master only |
false |
true |
| pulse.agent.offline.timeout |
Minimum amount of time, in seconds, that must pass without a successful ping before pulse™ will fail a stage because the connection to the agent appears to have been lost. |
master only |
4 * pulse.agent.ping.interval |
300 |
| pulse.agent.ping.interval |
The minimum time, in seconds, between rounds of agent pings. The actually time between the start of two rounds may be longer. |
master only |
60 |
180 |
| pulse.agent.ping.timeout |
The maximum time, in seconds, that the master will wait for a reply to a ping to an agent. If the agent does not reply in this time period, then it is deemed to be offline. |
master only |
45 |
30 |
| pulse.archive.command |
The external command to run to create zip archives if external archiving is turned on. See CB - Using External Archive Tools for details. |
master and agents |
zip -qry ${zipfile} ${files} |
myzip -o ${zipfile} ${files} |
| pulse.echo.passwords |
If set to any value, pulse™ will echo passwords when they are entered via the command line. Typically only used for debugging. |
tools only |
|
true |
| pulse.enable.request.logging |
If set to true, pulse™ will log web UI requests in NCSA format to files in the $PULSE_HOME/logs directory. Note that these logs can be large if there are many users (see also pulse.extended.request.logging and pulse.request.logging.retain.days). |
master only |
false |
true |
| pulse.extended.request.logging |
If true and request logging is enabled, requests will be logged in extended NCSA format. |
master only |
false |
true |
| pulse.feature.limit |
If non-zero, limits the number of each type (error, warning, etc) of message that will appear in result notification messages (e.g. emails). |
master only |
100 |
0 (to disable) |
| pulse.hessian.read.timeout |
If non-zero, the number of seconds after which to timeout idle connections between master and agents. |
master and agents |
60 |
0 (to disable) |
| pulse.jetty.idle.timeout |
The number of seconds after which to time out idle connections to the master or from the master to the agents on the receiving end. |
master and agents |
60 |
30 |
| pulse.jetty.max.threads |
The maximum number of threads to allocate for handling of HTTP requests (made by users of the web UI, remote API and agents to talk to the master). New in 2.0.47. |
master only |
250 |
500 |
| pulse.jetty.min.threads |
The minimum number of idle threads to keep ready for handling of HTTP requests. New in 2.0.47. |
master only |
25 |
50 |
| pulse.notification.test.failure.limit |
The maximum number of test failures to show in notifications. |
master only |
20 |
100 |
| pulse.p4.client.prefix |
The prefix used for all Perforce clients created by pulse™. |
master and agents |
pulse- |
my-prefix- |
| pulse.p4.client.command.timeout |
Maximum running time, in seconds, for a Perforce client name generation command before that command is killed. |
master and agents |
300 |
600 |
| pulse.p4.command |
Path (or name if in the PATH) of the command to execute as the Perforce command-line client. |
master and agents |
p4 |
/usr/local/bin/p4 |
| pulse.p4.command.<sub-command> |
Path (or name if in the PATH) of the command to execute as the Perforce command-line client for the particular Perforce sub-command. This allows overriding of the command-line for a single Perforce sub-command, e.g. sync by setting pulse.p4.command.sync. |
master and agents |
|
mysync |
| pulse.p4.inactivity.timeout |
Maximum period of inactivity (i.e. no output detected), in seconds, for a p4 child process before that process is killed. |
master and agents |
300 |
600 |
| pulse.recipe.dispatch.pool.size |
Number of threads to use for dispatching recipe requests to agents. (New in 2.0.44.) |
master only |
5 |
10 |
| pulse.request.logging.retain.days |
If request logging is enabled, the number of days request logs will be retained for (older logs are deleted). |
master only |
30 |
10 |
| pulse.retain.environment.case |
If set to any value, environment variables will not be normalised to upper case when converted to pulse™ file properties. |
master and agents |
|
true |
| pulse.suppressed.environment.variables |
A space-separated list of environment variables that should not have their values recorded in logs etc. |
master and agents |
P4PASSWD |
SECRET1 SECRET2 |
| pulse.test.failure.limit |
The maximum number of failed test cases to show in build summaries in the UI. |
master only |
100 |
50 |
| pulse.unarchive.command |
The external command to run to unpack zip archives if external archiving is turned on. See CB - Using External Archive Tools for details. |
master and agents |
unzip -qq ${zipfile} |
myunzip ${zipfile} |
| pulse.use.external.archiving |
If true, external zip/unzip tools will be used where available to create and extract archives. See CB - Using External Archive Tools for details. |
master and agents |
true |
false |
| pulse.use.external.copy |
If true, forces pulse™ to use the cp command when copying files. This property only needs to be explicitly set to true on Windows, it will default to true on other platforms where cp is found. For external copying to work, there must be a GNU-compatible cp command in the PATH of pulse™. For large copies, this can improve copy performance. |
master and agents |
true where cp is in the PATH, except on Windows |
true |
| pulse.use.native.process.kill |
Enables (experimental) native process termination on Windows, which kills the whole process tree when terminating a command. |
master and agents |
false |
true |
