Skip to main content

The most recent patch for this version is 1.10.2.  Learn more  

Version: 1.10

Deployment

There are configuration properties that are not included in the sample deployment configuration files that may be relevant for some users to add. These are described in this section.

Important

ADS cannot be running when the configuration is updated. Before editing any configuration file, stop ADS. Perform the edits, and then restart ADS for the new configuration to take effect.

License expiration warning

ADS will warn in a log message when the license is nearing its expiration date. By default, that warning is triggered 30 days before the expiration date.

You can override this by adding an optional property entry to the license property. This will control how many days before the license expires that a warning should be triggered and logged.

license: <path_to_valid_license_file>
licenseExpirationWarning: 100 days

License expiration warning

  1. Locate the license: property in the deployment configuration file.

  2. Add the licenseExpirationWarning: property and set a duration for the number of days before the license expires that a warning should be triggered and logged.

The log entry will look something like this:

WARN [2020-07-08 08:50:34,489] com.axiomatics.ads.license.LicenseChecker: License expires in 100 days

Connection pooling

When using standard attribute connectors that rely on database access via JDBC, setting parameters for the connection pool may be considered. Suitable values for this is best determined for the execution environment in question.

note

For both property values, Axiomatics recommends starting with low values and work upwards in small increments.

attributeConnectorContext:
jdbc:
connectionPool:
maximumSize: 5
minimumSize: 1

Connection pool configuration

  1. Open the deployment configuration file in a text editor.

  2. Add the property attributeConnectorContext:

  3. Add the subproperty jdbc:

  4. Add the subproperty connectionPool:

There are two property values to set:

  • maximumSize: This property controls the maximum size that the pool is allowed to reach, including both idle and in-use connections. This value will determine the maximum number of connections to the database backend. The value must be a non-negative integer. If the value is zero, or not set, connection pooling will not be used. The recommended starting value is 5.

  • minimumSize: Each instance of a Table or SQL attribute connector will create a connection pool of this size on startup. The connection pool will never be smaller than this. If the value is zero, or not set, the connections will not be created until needed. The recommended starting value is 1.

Connections above the minimum number will be closed after a 10-minute period of inactivity. (As of this release, this is not configurable.)

Number of concurrent requests

For performance reasons (to avoid long response times and maximize throughput), a parameter for the maximum number of concurrent requests may be considered.

  1. Open the deployment configuration file in a text editor.

  2. Locate the server: property.

There is one value to set:

  • maxThreads: This property controls the maximum number of threads to use for requests. Suitable values for this is best determined by the execution environment in question. The default value is 1024. It should not be set to a value lower than 8.

Concurrent evaluation of Multiple Decision Profile requests

The presence of this configuration object enables concurrent, or multi-threaded, evaluation of Multiple Decision Profile (MDP) requests. If this object is missing, all evaluations will be sequential.

  1. Open the deployment configuration file in a text editor.

  2. Add the property concurrentEvaluation:

There is one property value to set:

  • numberOfWorkers: This property controls the number of workers that will perform the decision request evaluations in parallel. The value must be a positive integer.
note

Multiple Decision Profile (MDP) is a standards-based way of grouping multiple similar access requests into a single "batch" request which will reduce the performance cost incurred by over-the-network use. See the Multiple Decision Profile specification, for more information.