Skip to content

v6.2.0

Choose a tag to compare

View all tags
@elrayle elrayle released this 18 Feb 02:58
v6.2.0
149e1ca
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

Actions Required to Upgrade

It is recommended that you update to this version if you are using any version from v5.2.0 upward. That release introduced the performance cache which has since been identified as the source of a memory leak. This release addresses that issue and provides more control over debugging loggers.

Update to qa_server v6.2.0 and run bundle install.

bundle update qa_server

Changes

Migrations

The scenario_run_history table has a new indexed column with the date of the run. This allows for more efficient calculations of the summary data for the history datatable and graph.

Run the migration install task to get the new migration:

rake qa_server:install:migrations

This should add migration:

  • _add_date_column_to_scenario_run_history.qa_server.rb

Run migrations:

rake db:migrate

Debug logging

In v6.0.0, a logger was added for debugging the Monitor Status page, especially for tracking the caching of the generated statistics for that page. In this release, a second logger was added for debugging the performance cache. Also, all messages going to both these loggers are set using the debug level.

The default location for the monitor_logger is log/monitor.log. It can be changed by setting ENV['MONITOR_LOG_PATH'].

The default location for the performance_cache_logger is log/performance_cache.log. It can be changed by setting ENV['PERFORMANCE_CACHE_LOG_PATH']

These debugging loggers can be controlled by configuration options. See below for details.

New Configuration Options

There are several new configurations all of which are optional and have a default values.

logger related configs

Both loggers follow the default behavior of the Rails logger. That is, logger level for development is debug and logger level for production is info. The result of this is that both logs will by default be created in the development environment and will not for production. You can control this in all environments using the following configurations.

  # Enable/Disable logging of performance cache
  # Uncomment one of the lines below to enable or disable performance cache logging.  NOTE: By default, loggers follow the
  # default levels for Rails loggers (i.e. enabled for development, disabled for production.)
  # config.enable_performance_cache_logging
  # config.disable_performance_cache_logging

  # Enable/Disable logging of monitoring process
  # Uncomment one of the lines below to enable or disable monitoring process logging.  NOTE: By default, loggers follow the
  # default levels for Rails loggers (i.e. enabled for development, disabled for production.)
  # config.enable_monitor_status_logging
  # config.disable_monitor_status_logging

max performance cache size

Previously by default, the cache was written to the database once a day when the monitoring tests were run. There was a problem with the performance cache growing too large in previous releases during heavy usage. To address this, a configuration was added to set a max size for the cache. If it is exceeded, the cache will be written to the database immediately and the cache reset. To control the max size, set the following configuration.

  # Maximum amount of memory the performance cache can occupy before it is written to the database.
  # @param [Integer] maximum size of performance cache before flushing
  # config.max_performance_cache_size = 32.megabytes

updating configurations for existing apps

It is recommended that you copy the new configurations to keep your local config file in sync with the configurations.

Copy only the new configs...

FROM: lib/generators/qa_server/templates/config/initializers/qa_server.rb
TO: config/initializers/qa_server.rb

authentication required for refreshing monitor tests

Questioning Authority (QA) has an authentication token for reloading authorities through the browser. QaServer makes use of that same token to control refreshing of data on the Monitor Status page. This addresses the potential risk of a denial of service attack where repeatedly requesting a refresh could exceed application resources.

You can set the authentication token in the QA initializer. (i.e., config/initializers/qa.rb)

Change Log

  • use authentication for refreshing monitor tests
  • add performance cache logger
  • exceeding max performance cache size flushing the cache
Assets 2
Loading