Skip to main content
Version: 7.9

Gateway Configuration File Reference

This section details the various configuration changes that can be made to the Gateway's configuration file: ignition.conf. Before the Gateway starts, a wrapper service checks the configuration file for parameter values, and then attempts to start the Gateway using parameters. This means changes made to the configuration file will only occur on startup, and making changes to the configuration file while the Gateway is already running will not have any impact until a restart.

Configuration File Location

On Windows and OSX the Gateway's configuration file can be found at %IgnitionInstallationDirectory%/data/ignition.conf.

On Linux, the file is located at etc/ignition/ignition.conf.

Once you have located the file, open it in your text editor of choice to start making changes.

Comments in the File

Many lines in the configuration file are commented out, either to provide some documentation in the file, or to omit certain parameters, such as some options under the Java Additional Parameters header. The "#" character is used to comment lines in the configuration file.

# this line is commented
this line is not commented

Gateway Memory Allocation

Inductive University

Changing Gateway Memory Allocation

Watch the video

On a standard installation, the Gateway is initially allocated a fixed amount of heap (memory). Increasing this allows the Gateway to utilize more of the server's memory. To determine if this is necessary, navigate to the Performance page under the Status section of the Gateway webpage. Generally speaking, if the Memory Trend shows a saw tooth pattern that peaks towards the maximum amount of memory, that's expected behavior. However, if memory usage usually floats around maximum allocated, and slow response events occur more than occasionally, then it may be time to consider increasing the maximum allocated memory, assuming the server has available memory.

To increase the maximum amount of memory allocated to the Gateway, open the Gateway configuration file, and search for wrapper.java.maxmemory. It should look something like following:

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

The number at the end of the line represents the maximum amount of memory allocated to the Gateway (in megabytes). To change the amount of memory allocated to the Gateway, simply change this number, save the configuration file, and restart the Gateway. Once the Gateway starts up again, it will attempt to use the amount of memory specified.

The new heap size shouldn't exceed the amount of memory available, nor should you allocate all of the server's memory to the Gateway because the server likely has other applications (including the host operating system) that also need to make use of the system's resources.

Changing Java Additional Parameters

caution

Adding or modifying parameters in the configuration file is considered an advanced configuration change. Most installations don't require any additional parameters, nor do they require modification to existing parameters. We generally discourage most users from making changes to parameters in the configuration file, as doing so could result some unintended behavior or security vulnerabilities. We list the parameters on this page for the sake of transparency.

If you choose to add or modify parameters in the the configuration file, you do so at your own risk.

A section of the configuration file contains a header stating "Java Additional Parameters". This section allows for a large number of configuration changes, and merits having some discussion on how to add new parameters. On install, the Java Additional Parameters section may look like the following:

# Java Additional Parameters
wrapper.java.additional.1=-Ddata.dir=data
#wrapper.java.additional.2=-Xdebug
#wrapper.java.additional.3=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:8000

When adding a new parameter, the wrapper.java.additional.# prefix must be added to a new line. Each parameter contains a prefix (wrapper.java.additional.#), a key, and a value that the key will be set to. Generally speaking, each parameter in the file should follow the pattern below:

wrapper.java.additional.1=-key=value

Uncommented parameters should be listed in ascending numerical order, based on the number at the end of the prefix, as shown below.

# Add parameters like this:
wrapper.java.additional.1=-Ddata.dir=data
#wrapper.java.additional.2=-Xdebug
#wrapper.java.additional.3=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:8000
wrapper.java.additional.2=-some.thing=foo
wrapper.java.additional.3=-some.other.thing=bar


# Avoid skipping commented numbers:
wrapper.java.additional.1=-Ddata.dir=data
#wrapper.java.additional.2=-Xdebug
#wrapper.java.additional.3=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:8000
wrapper.java.additional.4=-some.thing=foo

Suppressing Error Message Details

New in 7.9.17
By default, error messages in the Designer and Client report a stack trace, which provides granular information about the source of the error. However in some cases, these stack traces may include sensitive information from the Gateway. You can restrict the amount of information presented in these error messages with the following parameter:
Example
wrapper.java.additional.#=-Dignition.xmlrpc.errorDetailSuppression=%Value%

Where %Value% is one of the following values:

ValueDescription
NONEErrors are not suppressed at all. This is functionally the same as not specifying the parameter at all. (default behavior)
CLIENTError messages for client sessions will be suppressed, but not designer sessions.
ALLError messages for both clients and the designer will be suppressed.

EAM Collect Backup Transfer Timeout

New in 7.9.20
By default, the EAM Collect Backup task will timeout if the Agent takes longer than 60 minutes to transfer the backup to the Controller over the Gateway Network. This setting can be adjusted by adding the following parameter, which expects an integer value in milliseconds:
wrapper.java.additional.1=-Dignition.eam.task.collectBackup.transferTimeout=3600000

Thread Pool Counts

In some testing and troubleshooting scenarios, it may be required to increase threadpool counts from their default settings. By default, the threadpool count is set to 5.

caution

While there is no limit on how high threadpool counts can be increased, be aware that resource usage such as CPU and RAM will also increase.

wrapper.java.additional.1=gateway-tagprovider-default-sc=10