Sepasoft - MES Modules
Cirrus Link - MQTT Modules
Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
Ignition 8.1. Offline Version (04/2021)
Ignition 8 Online Version
Ignition 7.9 Online Version
Ignition 7.8 Online Version
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.
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.
Caution:
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
wrapper.java.additional.#=-Dignition.xmlrpc.errorDetailSuppression=%Value%
Where %Value% is one of the following values:
| Value | Description |
|---|---|
| NONE | Errors are not suppressed at all. This is functionally the same as not specifying the parameter at all. (default behavior) |
| CLIENT | Error messages for client sessions will be suppressed, but not designer sessions. |
| ALL | Error messages for both clients and the designer will be suppressed. |
Gateways use more secure security headers. The default settings are listed below, along with their associated system properties. These parameters mainly impact Perspective sessions, as well as any pages hosted on Ignition's web server.
Note: HTTP headers used by the Gateway are configurable via the ignition.conf file in the Gateway's installation directory. In most cases there won't be a need to modify the new default values. However, if you're embedding a Perspective session inside of an iframe from another origin, and it stops working after upgrade, then take a look at this Knowledge Base Article for more details.
The following system properties interact with the Strict-Transport-Security header. Enabling the header involves setting the Dignition.https.sts.maxAge system property to a non-zero value. By default, the header is disabled.
| System Property | Description |
|---|---|
-Dignition.https.sts.maxAge | Sets the maximum age of the Strict Transport Security header. The value should be set to an integer, representing a number of seconds. |
-Dignition.https.sts.includeSubDomains | Applies the includeSubDomains parameter. Expects a boolean value. If omitted, defaults to false. |
-Dignition.https.sts.preload |
The following feature is new in Ignition version 8.1.5
Click here to check out the other new features This parameter allows websites to tell the browser to only connect using HTTPS. It can be set to " |
wrapper.java.additional.1=-Dignition.https.sts.maxAge=5000 wrapper.java.additional.2=-Dignition.https.sts.includeSubDomains=false wrapper.java.additional.3=-Dignition.https.sts.preload=true
The following system properties interact with the Referrer-Policy header: By default, the header is enabled with a value of strict-origin-when-cross-origin.
| System Property | Description |
|---|---|
-Dignition.http.header.referrer_policy.enabled | Allows you to enable or disable the Referrer-Policy header. Expects a |
-Dignition.http.header.referrer_policy.value | Sets the value of the Referrer-Policy. |
wrapper.java.additional.1=-Dignition.http.header.referrer_policy.enabled=true wrapper.java.additional.2=-Dignition.http.header.referrer_policy.value=strict-origin-when-cross-origin
The following system properties interact with the X-Content-Type-Options header: By default, the header is enabled with a value of nosniff .
| System Property | Description |
|---|---|
-Dignition.http.header.x_content_type_options.enabled | Allows you to enable or disable the X-Content-Type-Options header. Expects a |
-Dignition.http.header.x_content_type_options.value | Determines the value of the X-Content-Type-Options. |
wrapper.java.additional.1=-Dignition.http.header.x_content_type_options.enabled=true wrapper.java.additional.2=-Dignition.http.header.x_content_type_options.value=nosniff
The following system properties interact with the X-Frame-Options header: By default, the header is enabled with a value of SAMEORIGIN.
| System Property | Description |
|---|---|
-Dignition.http.header.x_frame_options.enabled | Enables or disables the X-Frame-Options header. |
-Dignition.http.header.x_frame_options.value | Determines the value of the X-Frame-Options header |
wrapper.java.additional.1=-Dignition.http.header.x_frame_options.enabled=true wrapper.java.additional.2=-Dignition.http.header.x_frame_options.value=SAMEORIGIN
The following system properties interact with the X-XSS-Protection header. By default, the header is enabled with a value of 1; mode=block.
| System Property | Description |
|---|---|
-Dignition.http.header.x_xss_protection.enabled | Enables or disables the X-XSS-Protection header. |
-Dignition.http.header.x_xss_protection.value | Determines the value of the X-XSS-Protection header. |
wrapper.java.additional.1=-Dignition.http.header.x_xss_protection.enabled=true wrapper.java.additional.2=-Dignition.http.header.x_xss_protection.value=1; mode=block
| System Property | Description |
|---|---|
-Dignition.http.client.manager.cookieSpec | Controls the cookie parsing behavior of the HTTP Client. This system property may take one of the following values:
|
-Dignition.http.client.manager.socket.keepalive | When set to |
-Dignition.http.client.manager.pool.idleConnectionCheckInterval | An integer representing the duration in seconds between each check for idle connections. This value is ignored when maxIdleConnectionTime is less than or equal to zero. If this value is undefined or less than or equal to zero, then the interval is set to match maxIdleConnectionTime. |
-Dignition.http.client.manager.pool.maxIdleConnectionTime | An integer representing the number of seconds that connections in the HTTP connection pool may be idle (i.e. no data is sent or received on the socket) before it is evicted and closed. If set to any number less than or equal to zero or undefined, idle connection eviction will be disabled. |
-Dignition.http.client.manager.proxy.enabled | If set to true, the HTTP Client will respect the JVM's system default proxy settings. Default value if undefined is false. |
wrapper.java.additional.1=-Dignition.http.client.manager.cookieSpec=standard-strict wrapper.java.additional.2=-Dignition.http.client.manager.socket.keepalive=true wrapper.java.additional.3=-Dignition.http.client.manager.pool.idleConnectionCheckInterval=60 wrapper.java.additional.4=-Dignition.http.client.manager.pool.maxIdleConnectionTime=300 wrapper.java.additional.5=-Dignition.http.client.manager.proxy.enabled=true
For Windows:
Navigate to \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Modifying the registry can cause serious problems and impact your server's performance if done incorrectly. For information on how to back up and restore the registry in Windows, click here.
If parameters for \KeepAliveTime and \KeepAliveInterval do not exist, create them.
Click Edit>New>DWORD (32-bit) Value.
Open the Registry Editor.
Add the following parameters:
| Name | Data Type | Range | Default value |
|---|---|---|---|
| KeepAliveTime | REG_DWORD | 0x1–0xFFFFFFFF (milliseconds) | 0x6DDD00 (7,200,000 milliseconds = 2 hours) |
| KeepAliveInterval | REG_DWORD | 0x1–0xFFFFFFFF (milliseconds) | 0x3E8 (1,000 milliseconds = 1 second) |
Exit the Registry Editor.
Restart the computer for changes to take effect.
For Linux:
For Linux systems, there are three parameters to change:
| Name | Default value |
|---|---|
| tcp_keepalive_time | 7200 (seconds) |
| tcp_keepalive_intvl | 75 (seconds) |
| tcp_keepalive_probes | 9 (number of probes) |
Edit /etc/sysctl.conf:
# vi /etc/sysctl.conf
Add the following settings:
net.ipv4.tcp_keepalive_time = #newvalue net.ipv4.tcp_keepalive_intvl = #newvalue net.ipv4.tcp_keepalive_probes = #newvalue
This parameter allows you limit the amount of data that can be posted back from a browser or other client, to the Gateway. Generally, this is useful to increase the maximum size for Web Dev POST requests. More information about this parameter can be found in Jetty's documentation . Note: By default, the maximum size is kept low on the default installation to prevent DoS attacks. We do not recommend changing this, especially so if the Gateway isn't in a closed network.
wrapper.java.additional.1=-Dorg.eclipse.jetty.server.Request.maxFormContentSize=2000000
wrapper.java.additional.1=-Dignition.internalDbMaxWait=60000
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).
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.
wrapper.java.additional.1=-Dignition.hostedLaunchers=true
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".
wrapper.java.additional.1=-Dignition.hostedLauncherVersion=8.1.0
wrapper.java.additional.1=-Dignition.automaticThreadDump.sampleRate=60
You can specify which edition of Ignition a Gateway should be set to with the parameter demonstrated below.
wrapper.java.additional.1=-Dedition=standard
Caution: Ignition Gateway Licenses are matched to a specific edition. Changing the edition of an Ignition Gateway that is already licensed can result in the license becoming invalidated. It's recommended that you unactivate a license on a gateway before changing its edition.
standardedgemakerNormally, an Ignition Gateway will not allow unsigned module to be installed. This restriction can be disabled with the flag below. This is normally done in cases where a user is developing a custom module, and wants to install it without having the module signed.
wrapper.java.additional.1=-Dignition.allowunsignedmodules=true
This setting dictates how often the Ignition Gateway will scan its project directory for changes. As of Ignition 8.1.0 this was changed to a 300 second rate (from a 10 seconds rate), but it can be configured. This is useful in cases where project files are being modified from external sources and the gateway needs to be aware of theses changes in a more timely manner. The argument below expects an integer, which represents a number of seconds.
wrapper.java.additional.1=-Dignition.projects.scanFrequency=100
wrapper.java.additional.1=-Dignition.projects.ignoredFiles=Folder1:Folder2:Folder3
By specifying a folder to ignore, note that any folder within the data/projects folder with the same name will be excluded, including any projects with that name. For example, if you exclude a folder called "test" and your project name is also "test" the project will be excluded as well.
In redundant systems, both alarm event and alarm shelf items wait in separate queues on the active node before they're transferred to the inactive node. Normally the active node sends recently changed alarm events and shelve events to the inactive node as they occur. However if the queue becomes full the active node will pause this behavior and send a full transfer to the inactive node, ensuring that the state of events on the inactive node is accurate.
| System Property | Description |
|---|---|
| -Dalarm.redundancy.runtimeupdates.max | Determines the maximum size of the alarm events queue. Defaults to 2,000,000 if omitted. |
| -Dalarmshelf.redundancy.runtimeupdates.max | Determines the maximum size of the alarm shelf queue. Defaults to 2,000,000 if omitted. |
wrapper.java.additional.1=-Dalarm.redundancy.runtimeupdates.max=1000000 wrapper.java.additional.2=-Dalarmshelf.redundancy.runtimeupdates.max=1000000
By default, gateway remote providers can only "hop" two gateways away. For example, assume the numbers below represent gateways, which are all connected over a gateway network.
1 -- 2 -- 3 -- 4
Normally, gateway 1 only has access to gateway 2 and 3. Gateway 4 is too far away. However this can be changed by adding the following to Gateway 1's configuration file:
wrapper.java.additional.1=-Dignition.gan.maxproxydepth=3
Note: The Allow Proxying setting must be enabled for requests to be forwarded in this manner.
The following system properties interact with EAM. These settings allow you to configure the timeout settings for various possible actions in EAM.
| System Property | Description |
|---|---|
-Dignition.eam.task.collectBackup.transferTimeout=3600000 |
The following feature is new in Ignition version 8.1.17
Click here to check out the other new features |
| -Dignition.eam.freeSpace.timeout.millis |
The following feature is new in Ignition version 8.1.18
Click here to check out the other new features |
Perspective Sessions cache assets (our CSS, JS, fonts, and images) to reduce load times after the first time opening the project. Sessions will cache assets, but some browsers will attempt to re-download assets on refresh. This is mostly controlled by the browser instead of Ignition so there are some important differences between browsers.
Chrome and Safari handle browser cache differently than Edge and Firefox when it comes to hitting the ‘refresh’ or ‘reload’ button. Edge and Firefox both seem to send a request for new copies of the resources with header of max-age=0 instead of pulling from the cache. Navigating via a 'back’ button or entering in the URL bar and pressing ‘enter’ will load from cache. This seems to simply be a design difference by these two browsers, in which both are working as intended.
Caching can be disabled via the following flag:
wrapper.java.additional.1=-Dperspective.gateway.disableClientCaching=true
Alternatively the cacheControl flag can be used to modify aspects of the cache. You can learn more about cache control from the MDN documentation. The example below lists some default values:
wrapper.java.additional.1=-Dperspective.gateway.cacheControl=public,max-age=2419400,no-transform
| System Property | Description |
|---|---|
-Dperspective.fetch-concurrency | Determines the number of concurrency sessions. Defaults to 25. |
-Dperspective.fetch-timeout | Determines the timeout period when receiving project updates. Defaults to 5000 milliseconds. |
wrapper.java.additional.1=-Dperspective.fetch-concurrency=25 wrapper.java.additional.2=-Dperspective.fetch-timeout=5000
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.
wrapper.java.additional.1=-Dperspective.ws.disablePermessageDeflateExtension=true
| System Property | Description |
|---|---|
-Dperspective.websocket.max-message-size | Specifies the maximum message size in KB. Default value is 2048. |
wrapper.java.additional.1=-Dperspective.websocket.max-message-size=2048
| System Property | Description |
|---|---|
-Dperspective.threadpool.perspective-worker.keep-alive | Specifies the keep-alive period. Expects an integer, which represents an amount of seconds. When omitted, defaults to 60 seconds. Note that this setting is ignore if pool-size (listed below) is set. |
-Dperspective.threadpool.perspective-worker.pool-size | Specifies the maximum number of workers as an integer. When omitted, defaults to unlimited. |
wrapper.java.additional.1=-Dperspective.threadpool.perspective-worker.keep-alive=40 # These settings are mutually exclusive, so setting both will result in the keep-alive being ignored # wrapper.java.additional.1=-Dperspective.threadpool.perspective-worker.pool-size=100
wrapper.java.additional.1=-DStoreAndForwardStatusTagRefreshRate=####
Where "####" is the rate in milliseconds that the Tags should refresh at. Default refresh rate is 5000 milliseconds.
SELECT "tagid", "intvalue", "floatvalue", "stringvalue", "datevalue", "t_stamp", "dataintegrity"
FROM sqlth_1_data
WHERE "t_stamp" >= 1580680800000 AND "t_stamp" <= 1581026400000
AND ( "tagid" = 14568 OR "tagid" = 14571 OR "tagid" = 14572 )
ORDER BY "t_stamp" ASC, "tagid" ASC
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:
SELECT "tagid", "intvalue", "floatvalue", "stringvalue", "datevalue", "t_stamp", "dataintegrity"
FROM sqlth_1_data
WHERE "t_stamp" >= 1580680800000 AND "t_stamp" <= 1581026400000
AND "tagid" IN (14568, 14571, 14572)
ORDER BY "t_stamp" ASC, "tagid" ASC
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:
wrapper.java.additional.1=-Dignition.taghistorian.useLegacyQuerySyntax=true