HELM configuration
| Parameter | Description | Mandatory | Default Value |
|---|---|---|---|
|
The maximum payload size in MB that trinity-core-service accepts via HTTP. The payload size is taken from the header and does not cover intentional misuse. |
no |
|
|
Enables or disables the caching of MACMA tokens. |
no |
|
|
Time a token MACMA token is cached. |
no |
|
|
Number of AMQP0.9.1 messages to prefetch. |
no |
|
|
Number of AMQP consumers. |
no |
|
|
Maximum number of AMQP consumers. |
no |
|
|
This parameter adds a time limitation to the database query for reading data, used in the auto-completion. This can be set for improving performance on environments with a high retention configuration. |
no |
|
|
This property sets the scheduler interval where a tenant’s MDM master data synchronization is retried after PQM got a missing permission error. |
no |
|
|
This property defines after what time a stale migration is considered orphan and picked up by the orphan detection scheduler. |
no |
|
|
This property sets the scheduler interval to identify and recover orphan synchronizations. This can occur if a service instance is stopped within a synchronization. A recovery will be started ones detected. |
no |
|
|
This property sets the scheduler interval where a tenant’s MDM master data synchronization is retried after PQM detected a corrupted state. |
no |
|
|
Maximum pool size for datasource. |
no |
|
|
If maxLifetime is configured, create a future End-of-life task with 2.5% variance from the maxLifetime time to ensure there is no massive die-off of Connections in the pool. Defaults to 110000 ms (110s) which is lower than the AzureSQL default (which is 120s). |
no |
|
|
The maximum number records that are to a batch in one transaction before persisting in the database. |
no |
|
|
The maximum number of intelligence records that add added to a batch before persisting in the database. This should be aligned with 'local.trinityCore.relationalDbMaxBatchSize'. |
no |
|
|
Log level for InfluxDB |
no |
|
|
The attribute of the retention policy that determines how many copies of the data are stored in the cluster. Replicating copies ensures that data is accessible when one or more data nodes are unavailable. InfluxDB replicates data across N data nodes, where N is the replication factor. Note: This property is only considered when PQM creates the database. PQM only creates the database if the database does not exist at the service startup and if the database user has the relevant permissions. Also, this parameter will be considered only ones on database creation time. Changing this configuration at a later point in time needs to be done in the database. |
no |
|
|
The process retention policy configuration has two responsibilities: . Setting the retention policy. Retention policy is the part of InfluxDB data structure that describes for how long InfluxDB keeps data. Note: The retention policy is only set when PQM creates the database. PQM only creates the database if the database does not exist at the service startup and if the database user has the relevant permissions. Also, this parameter will be considered only ones on database creation time. Changing this configuration at a later point in time needs to be done in the database. . Defines how far into the past processes are searched for. Important: If the retention policy is set in the database, this configuration must also be set to this configuration property. A mismatch between the database configuration and this property negatively impact the system functionality. E.g. processes cannot be found. |
no |
|
|
Defines if sending a process with the same timestamp again will override an existing process in the database or not. |
no |
|
|
Number of actions when persisting process messages in the InfluxDB. Consult the InfluxDB documentation for more information. |
no |
|
|
Number of the batch buffer limit when persisting process messages in the InfluxDB. Consult the InfluxDB documentation for more information. |
no |
|
|
Log level for framework |
no |
|
|
Log level for AMQP |
no |
|
|
Log level for messaging |
no |
|
|
Log level for security |
no |
|
|
Log level for Spring Web |
no |
|
|
Log level for web server |
no |
|
|
Log level for database migration |
no |
|
|
Log level for Hibernate |
no |
|
|
Log level for metrics |
no |
|