Changing Java Additional Parameters
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:
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.
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:
Uncommented parameters should be listed in ascending numerical order, based on the number at the end of the prefix, as shown below.
Gateway Security HTTP Headers and Configuration
Gateways use more secure security headers. The default settings are listed below, along with their associated keys. These parameters mainly impact Perspective sessions, as well as any pages hosted on Ignition's web server.
Strict Transport Security
The following keys interact with the Strict-Transport-Security header. Enabling the header involves setting the
Dignition.https.sts.maxAge key to a non-zero value. By default, the header is disabled.
Sets the maximum age of the Strict Transport Security header. The value should be set to an integer, representing a number of seconds.
|Applies the |
This parameter allows websites to tell the browser to only connect using HTTPS. It can be set to "
The following keys interact with the Referrer-Policy header: By default, the header is enabled with a value of
Allows you to enable or disable the Referrer-Policy header. Expects a
Sets the value of the Referrer-Policy.
X Content Type Options
The following keys interact with the X-Content-Type-Options header: By default, the header is enabled with a value of
Allows you to enable or disable the X-Content-Type-Options header. Expects a
Determines the value of the X-Content-Type-Options.
X Frame Options
The following keys interact with the X-Frame-Options header: By default, the header is enabled with a value of
Enables or disables the X-Frame-Options header.
Determines the value of the X-Frame-Options header
X XSS Protection
The following keys interact with the X-XSS-Protection header. By default, the header is enabled with a value of
Enables or disables the X-XSS-Protection header.
Determines the value of the X-XSS-Protection header.
Perspective Web Socket Compression
You can remove the compression header for perspective web socket connections.
This parameter is generally only used in cases where a Microsoft IIS based firewall is acting like a reverse proxy, and needs to be able to rewrite secure web-socket messages.
Maximum Form Size
Hosted Launcher Installers
Normally, each Ignition Gateway includes files for the various launchers. When you download a launcher from a Gateway, it simply streams its local launcher files. However, you can override this behavior, causing the Gateway to ignore it's local launcher files and instead download launchers from the internet. This is an uncommon configuration for most cases, as it was devised primarily to aid with systems where memory limitations are strict (such as physical devices that include preinstalled Ignition Gateways).
Enabling Hosted Launchers
The following parameter (and value) enables the use of hosted launchers. While enabled, the Gateway will only ever attempt to retrieve the hosted launchers, meaning it will ignore the local launcher files.
Hosted Launcher Version
By default, enabling Hosted Launchers will cause the Gateway to retrieve launchers version appropriate launchers: 8.0.0 launchers for 8.0.0 Gateways, 8.1.0 launchers for 8.1.0 Gateways, etc.
The parameter below can be used to explicitly state which launcher version to retrieve. Generally, this is not recommended, but can potentially be useful if you're looking for a specific launcher version. It requires that
-Dignition.hostedLaunchers is set to "true".
You can specify which edition of Ignition a Gateway should be set to with the parameter demonstrated below.
- Standard Ignition - standard
- Ignition Edge - edge
- Ignition Maker - maker
Tag Historian Query Syntax
The Ignition Tag Historian stores and queries data in a particular way. When a Tag has Tag History enabled on it, an entry is generated for this Tag inside the sqlth_te table in your database. This Tag's Tag path, along with other Tag attributes, are stored in this table. Every Tag entry in the sqlth_te table has a unique Tag id which is used by the Tag Historian to identify each Tag. Whenever we make any type of change to this Tag's historical configurations, such as its Tag Group for instance, the current sqlth_te table entry for this Tag becomes retired and a new, unretired entry for this Tag gets created with a new Tag id. Due to this dynamic, it is common for a Tag path in the sqlth_te table to be associated with more than one Tag id. When a Tag History query executes for a specific Tag, a check is made against the sqlth_te table for all the Tag id's that match this Tag's Tag path. These Tag id's are then used to build a dynamic SQL query like the one shown below:
When we query Tag history for a Tag with three Tag id's associated with its Tag path, the system uses repetitive OR clauses to account for all the Tag id's for this Tag. Additional OR clauses in this fashion can be hard for databases to optimize. For this reason, we changed the query generating mechanism to use the IN operator like so:
The use of the IN operator allows for better database side query optimization. Users who want to change their historian to use the old query constructor with OR operators can do so by placing the following system flag in the ignition.conf file:
Store and Forward
It is possible to adjust the refresh rate of the System Tag Provider's System Tags. To do so, add the following system flag in the ignition.conf file:
Where "####" is the rate in milliseconds that the Tags should refresh at. Default refresh rate is 5000 milliseconds.