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

The Gateway's configuration file can be found at:
 %IgnitionInstallationDirectory%/data/ignition.conf.

See the Installing and Upgrading Ignition page for default installation directories.

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

On this page ...


Gateway Memory Allocation

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. 

IULocgo

Changing Gateway Memory Allocation


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

Changing Common Localization Parameters

You may sometimes need to change Ignition's locale information in the Gateway Configuration File. The following parameters will allow you to change the most commonly used localization information.

# Locale - Language (United States English)
wrapper.java.additional.1=-Duser.language=en_US

# Locale - Country (United States)
wrapper.java.additional.2=-Duser.country=US

# Locale - Variant (English (United States, Computer)
wrapper.java.additional.3=-Duser.variant=POSIX

# Timezone (Pacific Time)
wrapper.java.additional.4=-Duser.timezone=America/Los_Angeles

Changing File Encoding Techniques

You might also need to change how your files are encoded. The following parameter will allow you to change the encoding technique to what you require.

# File Encoding (Using UTF-8)
wrapper.java.additional.1=-Dfile.encoding=UTF-8

Designer and Vision Client Parameters

Suppressing Error Message Details

The following feature is new in Ignition version 8.1.10
Click here to check out the other new features
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.

Vision Client Route Handling (H3)

The following feature is new in Ignition version 8.1.24
Click here to check out the other new features
The following parameters are used to modify route handling for Vision Clients. Changing the values for these parameters is not necessary, but increasing the values may help improve Vision Client launching in extremely busy systems, resulting in fewer browser timeouts.

System PropertyDescription
-Dvision.fetch-concurrency
Determines the number of concurrency Clients. Defaults to 25,
-Dvision.fetch-timeout
Determines the timeout period when receiving project updates. Defaults to 5000 milliseconds.


Gateway Parameters

Gateway Security HTTP Headers and Configuration

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. 

Strict Transport Security

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 PropertyDescription
-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 " true"  or " false"  to enable or disable the  preload  directive of the  Strict-Transport-Security  header. If omitted, defaults to false.

Example
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 
Referrer Policy

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 PropertyDescription
-Dignition.http.header.referrer_policy.enabled

Allows you to enable or disable the Referrer-Policy header. Expects a true or false value. 

-Dignition.http.header.referrer_policy.value

Sets the value of the Referrer-Policy.

Example
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
X Content Type Options

The following system properties interact with the X-Content-Type-Options header: By default, the header is enabled with a value of nosniff .

System PropertyDescription
-Dignition.http.header.x_content_type_options.enabled

Allows you to enable or disable the X-Content-Type-Options header. Expects a true or false value. 

-Dignition.http.header.x_content_type_options.value

Determines the value of the X-Content-Type-Options.

Example
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 
X Frame Options

The following system properties interact with the X-Frame-Options header: By default, the header is enabled with a value of SAMEORIGIN. 

System PropertyDescription
-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

Example
wrapper.java.additional.1=-Dignition.http.header.x_frame_options.enabled=true
wrapper.java.additional.2=-Dignition.http.header.x_frame_options.value=SAMEORIGIN
X XSS Protection

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 PropertyDescription
-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.

Example
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

HTTP Client Manager

The following feature is new in Ignition version 8.1.12
Click here to check out the other new features

The following system properties interact with the platform's HTTP Client. These settings allow you to configure how the IdP system and Perspective's HTTP Bindings parse cookies, handle idle HTTP connections, and respect proxy settings.


System PropertyDescription
-Dignition.http.client.manager.cookieSpec

Controls the cookie parsing behavior of the HTTP Client. This system property may take one of the following values:

  • default: Default cookie specification that picks up the best matching cookie policy based on the format of cookies sent with the HTTP response.
  • netscape: This CookieSpec implementation conforms to the original draft specification published by Netscape Communications. It should be avoided unless absolutely necessary for compatibility with legacy applications.
  • standard: Standard CookieSpec implementation that enforces a more relaxed interpretation of the HTTP state management specification (RFC 6265, section 5) for interoperability with existing servers that do not conform to the well-behaved profile (RFC 6265, section 4).
  • standard-strict: Standard CookieSpec implementation that enforces syntax and semantics of the well-behaved profile of the HTTP state management specification (RFC 6265, section 4).
-Dignition.http.client.manager.socket.keepalive

When set to  true , HTTP connections issued from the HTTP Client will set the  SO_KEEPALIVE  flag on the underlying socket, enabling keepalive. Enabling keepalive maintains a connection between a client and the server, reducing the number of TCP and SSL/TLS connection requests. You must also enable and configure keepalive settings on the OS running the Gateway. See KeepAlive Configuration. 

-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.
Example
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

KeepAlive Configuration

For Windows:

  1. 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.

  2. If parameters for \KeepAliveTime and \KeepAliveInterval do not exist, create them.

  3. Click Edit>New>DWORD (32-bit) Value.

  4. Open the Registry Editor.

  5. Add the following parameters:

    NameData TypeRangeDefault value
    KeepAliveTimeREG_DWORD0x1–0xFFFFFFFF (milliseconds)0x6DDD00 (7,200,000 milliseconds = 2 hours)
    KeepAliveIntervalREG_DWORD

    0x1–0xFFFFFFFF (milliseconds)

    		0x3E8 (1,000 milliseconds = 1 second)

  6. Exit the Registry Editor.

  7. Restart the computer for changes to take effect. 

For Linux:

For Linux systems, there are three parameters to change:

NameDefault value
tcp_keepalive_time7200 (seconds)
tcp_keepalive_intvl75 (seconds)
tcp_keepalive_probes9 (number of probes)


  1. Edit /etc/sysctl.conf:

    # vi /etc/sysctl.conf

  2. Add the following settings:

    net.ipv4.tcp_keepalive_time = #newvalue
net.ipv4.tcp_keepalive_intvl = #newvalue
net.ipv4.tcp_keepalive_probes = #newvalue

Maximum Form Size

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. 
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 . 

Example
wrapper.java.additional.1=-Dorg.eclipse.jetty.server.Request.maxFormContentSize=2000000

Internal Database Connection Timeout

The following feature is new in Ignition version 8.1.16
Click here to check out the other new features
The default maximum time that the Gateway will wait for a connection to an internal database is 30 seconds. This parameter allows you to override this setting and increase the maximum wait time.

Example
wrapper.java.additional.1=-Dignition.internalDbMaxWait=60000

Internal Database Maintenance Tasks

Internal Database VACUUM Operation

The following feature is new in Ignition version 8.1.23
Click here to check out the other new features
Starting in 8.1.23, a VACUUM operation is executed against the internal database upon Gateway startup by default. This operation reclaims unused disk space, trimming down on both the time it takes for auto-backups to complete, as well as the overall size of the internal database itself. This action can be disabled by using the following parameter.

Example
wrapper.java.additional.1=-Dignition.skipConfigDbVacuum=true

Internal Database Legacy Tag Cleanup

The following feature is new in Ignition version 8.1.23
Click here to check out the other new features
Upon Gateway startup, you can conduct a cleanup task on old 7.X.X SQLTAG tables. This helps to reduce bloated internal databases, save disk space, and potentially improve Gateway performance. Using the following parameter will opt the Gateway in for performing this cleanup task.

Example
wrapper.java.additional.1=-Dignition.tags.cleanupLegacyTagTables=true

Internal Database Project Table Cleanup

The following feature is new in Ignition version 8.1.23
Click here to check out the other new features
Upon Gateway startup, a cleanup task is conducted on old 7.X.X project tables. This helps to trim down internal databases, providing more space for other operations, and may improve Gateway performance. The following parameter will allow you to skip this cleanup operation. 

Example
wrapper.java.additional.1=-Dignition.projects.skipProjectRecordTableCleanup=true

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. 

Example
wrapper.java.additional.1=-Dignition.hostedLaunchers=true
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". 

Example
wrapper.java.additional.1=-Dignition.hostedLauncherVersion=8.1.0

Automatic Thread Dump Sample Rate

The following feature is new in Ignition version 8.1.13
Click here to check out the other new features
The following parameter can be used to override the default sample rate for Automatic Thread Dumps.  

Example
wrapper.java.additional.1=-Dignition.automaticThreadDump.sampleRate=60

Ignition Edition

You can specify which edition of Ignition a Gateway should be set to with the parameter demonstrated below. 

Example
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. 

Values
  • Standard Ignition - standard
  • Ignition Edge - edge
  • Ignition Maker - maker

Loading Unsigned Modules - "Developer Mode"

Normally, 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

Project Directory Scan Rate

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. 

Example
wrapper.java.additional.1=-Dignition.projects.scanFrequency=100

Ignored Project Directory Files

The following feature is new in Ignition version 8.1.15
Click here to check out the other new features
This setting allows users to specify a list of folders in the project directory that the Ignition Gateway will ignore when scanning for changes. By default, the Gateway will ignore changes to any files located within folders with the name ".git", ".svn", or ".hg". The argument below expects a list of additional folders to ignore, using the ':' character as a file separator.

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.

Redundant Alarm Runtime Limit

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 PropertyDescription
-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

Web Server

The following parameters are used to configure Ignition's default settings for web requests that are not configured in some other, more specific manner, such as Perspective Route Handling. These settings usually do not need to be modified, but a higher value may help mitigate issues on very busy systems.

System PropertyDescription
-Dignition.routes.defaultConcurrency
Determines the number of concurrent sessions allowed to acquire a lock per webserver route. The lock must be acquired within two seconds of an incoming request, or the request will return an error. Default is 5.
Example
wrapper.java.additional.1=-Dignition.routes.defaultConcurrency=5

Gateway Network Parameters

Proxy Depth

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:

Example
wrapper.java.additional.1=-Dignition.gan.maxproxydepth=3

Note: The Allow Proxying setting must be enabled for requests to be forwarded in this manner. 

GAN Queue Timeout

The following feature is new in Ignition version 8.1.22
Click here to check out the other new features
The Long Wait Queue timeout and Proxy Queue timeout can be adjusted if necessary for slower connections. These settings will mostly apply to EAM, but can also apply for more general GAN instances such as a GWBK transferring from a redundant master to a backup. 

System PropertyDescription

-metro.queues.proxyQueue.timeoutSecs

By default, the Proxy Queue will timeout after 60 minutes. This can be adjusted by setting the system property shown. 

-metro.queues.longWaitQueue.timeoutSecs

This parameter will adjust the Long Wait Queue timeout setting. The Long Wait Queue defaults to handle messages that take up to an hour to deliver if left unchanged.

EAM Timeout

The following system properties interact with EAM. These settings allow you to configure the timeout settings for various possible actions in EAM.

System PropertyDescription

-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
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 aforementioned parameter, which expects an integer value in milliseconds.

-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
This parameter will allow for adjusting the timeout setting that checks if there is sufficient free space to perform the EAM Controller's save operations. Expects an integer value in milliseconds. Default value is 10,000 milliseconds (10 seconds).


Perspective Parameters

Session Caching 

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

Perspective Session Route Handling

The following feature is new in Ignition version 8.1.8
Click here to check out the other new features
The following parameters are used to modify route handling for Perspective Sessions. Most systems will not need to modify these parameters. However increasing the values of these parameters may be helpful in cases where large project updates are sent out to active Perspective Sessions over a spotty network. A low timeout and concurrency in that scenario may result in browser timeouts. If these values are not set, Perspective will use the global routing values instead. See the Web Server section for more details on global routing.

System PropertyDescription
-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. 

Example
wrapper.java.additional.1=-Dperspective.fetch-concurrency=25
wrapper.java.additional.2=-Dperspective.fetch-timeout=5000

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.

Example
wrapper.java.additional.1=-Dperspective.ws.disablePermessageDeflateExtension=true

Perspective Web Socket Message Size

The following feature is new in Ignition version 8.1.12
Click here to check out the other new features
The following parameter can be used to specify the maximum web socket message size. Most systems will not need to modify this parameter. Increasing the maximum message size may be helpful if your project includes very large Perspective views.

System PropertyDescription
-Dperspective.websocket.max-message-size
Specifies the maximum message size in KB. Default value is 2048.
Example
wrapper.java.additional.1=-Dperspective.websocket.max-message-size=2048

Perspective Threadpool Restrictions

The following feature is new in Ignition version 8.1.12
Click here to check out the other new features
Perspective has two primary threadpools:

  • A "worker" threadpool (used for long-running, "blocking" work)
  • A "queue" threadpool (used for short-duration internal tasks)

By default, each of these pools can have an unlimited number of threads with a 60 second keep-alive. The following parameters can be used to fix the number of threads or change the keep-alive period. This can be useful in troubleshooting scenarios when attempting to limit the number of threads. 

System Property (Worker)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. 
Example
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
System Property (Queue)Description
-Dperspective.threadpool.perspective-queue.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-queue.pool-size
Specifies the maximum number of workers as an integer. When omitted, defaults to unlimited. 
Example
wrapper.java.additional.1=-Dperspective.threadpool.perspective-queue.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-queue.pool-size=100

Perspective Cache and Share

The following feature is new in Ignition version 8.1.12
Click here to check out the other new features
Certain bindings and queries in Perspective will often pull data to see if any values have changed. You can influence whether Perspective pulls in cached data or issues a new query by setting the timeout threshold before Perspective executes a new query. In other words, if Perspective fetches data that is within that time frame, the cached value will be used instead of a new, queried value. This timeout value can be modified with the following system property:

System PropertyDescription
-Dperspective.value-cache.max-age
Controls how long Cache and Share will keep cached values alive for before Perspective polls for new data. Default is 1 minute.
Example
# "####" is the timeout period for using cached data.
wrapper.java.additional.1=-Dperspective.value-cache.max-age=####


Store and Forward Parameters

The following feature is new in Ignition version 8.1.2
Click here to check out the other new features
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:

Example
wrapper.java.additional.1=-DStoreAndForwardStatusTagRefreshRate=####

Where "####" is the rate in milliseconds that the Tags should refresh at. Default refresh rate is 5000 milliseconds. 


Tag Historian Parameters

Tag Historian Query Syntax

The following feature is new in Ignition version 8.1.2
Click here to check out the other new features
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:

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:

Example
wrapper.java.additional.1=-Dignition.taghistorian.useLegacyQuerySyntax=true


  • No labels