{warning}*Deprecated* - Please install [GWME-7.1.1-11 - Foundation update with Advanced LDAP] instead.{warning}
h2. Problem
In its default configuration, the Groundwork Enterprise status viewer is designed to reflect current status updates with a minimal amount of time lag between an actual update and when the update is reflected on the portal. To minimize impact on system resources, this process involves logic to detect system changes and update the status viewer accordingly. It has been observed for some larger Groundwork installations that this process can result in unacceptable amounts of delay, in some cases as large as 3-5 minutes.
h2. Solution
For customers who are experiencing this problem, an option is being provided in this tech bulletin to allow configuring the status viewer to auto-refresh, which will help ensure that the status viewer is accurate with a shorter and more predictable delay. It should be noted that this option can increase the load on the Groundwork server, depending on the number of hosts/services and the frequency of the refreshes.
h2. Configuration
Installing this TB will instruct the user to add a line to {{/usr/local/groundwork/config/status-viewer.properties}} to specify the time gap (in seconds) between successive auto-refreshes.
{{portal.statusviewer.autoRefreshGap=30}}
This is defined as a time gap instead of a simple time period to ensure that if refreshes are taking a long amount of time due to transient system load (such as at startup) we do not run into a scenario where a refreshes back-up and cause the Groundwork server to become unresponsive. For most users, a value of 30 seconds is a good default to balance user experience with system load, but this value can be increased to a larger value to reduce system load. Decreasing this value can result in an improved user experience but beware that this can result in a significant strain which may have unacceptable impacts to monitoring performance.
h2. *Installing *
# Download the .tar.gz contain the new files and the install script.
# Extract the contents of the .tar.gz file.
# Change access permissions to the TB7.1.1-8_install script (e.g. chmod \+x …) and execute script as root.
{attachments:patterns=TB7.1.1-8.tar.gz-deprecated}
\\
h2. Uninstalling
# Change access permissions to the TB7.1.1-8_uninstall script (e.g. chmod \+x …) and execute script as root.
The log file in the common/var/patches directory contains the record of all installs and uninstalls as you do them.
h2. Problem
In its default configuration, the Groundwork Enterprise status viewer is designed to reflect current status updates with a minimal amount of time lag between an actual update and when the update is reflected on the portal. To minimize impact on system resources, this process involves logic to detect system changes and update the status viewer accordingly. It has been observed for some larger Groundwork installations that this process can result in unacceptable amounts of delay, in some cases as large as 3-5 minutes.
h2. Solution
For customers who are experiencing this problem, an option is being provided in this tech bulletin to allow configuring the status viewer to auto-refresh, which will help ensure that the status viewer is accurate with a shorter and more predictable delay. It should be noted that this option can increase the load on the Groundwork server, depending on the number of hosts/services and the frequency of the refreshes.
h2. Configuration
Installing this TB will instruct the user to add a line to {{/usr/local/groundwork/config/status-viewer.properties}} to specify the time gap (in seconds) between successive auto-refreshes.
{{portal.statusviewer.autoRefreshGap=30}}
This is defined as a time gap instead of a simple time period to ensure that if refreshes are taking a long amount of time due to transient system load (such as at startup) we do not run into a scenario where a refreshes back-up and cause the Groundwork server to become unresponsive. For most users, a value of 30 seconds is a good default to balance user experience with system load, but this value can be increased to a larger value to reduce system load. Decreasing this value can result in an improved user experience but beware that this can result in a significant strain which may have unacceptable impacts to monitoring performance.
h2. *Installing *
# Download the .tar.gz contain the new files and the install script.
# Extract the contents of the .tar.gz file.
# Change access permissions to the TB7.1.1-8_install script (e.g. chmod \+x …) and execute script as root.
{attachments:patterns=TB7.1.1-8.tar.gz-deprecated}
\\
h2. Uninstalling
# Change access permissions to the TB7.1.1-8_uninstall script (e.g. chmod \+x …) and execute script as root.
The log file in the common/var/patches directory contains the record of all installs and uninstalls as you do them.