Overview
Version
| Report Server Version |
|---|
| 11.0 |
Problem Description
When configuring some common parameters in the cluster, you need to manually add or modify fields in the database, which leads to the following two problems:
You are uncertain about when to configure these parameters or what these parameters mean, requiring backend support.
Modifying fields in the database incurs a certain operational cost.
Solution
FineReport has opened the platform configuration entry for common cluster parameters, allowing you to configure the parameters as needed. Currently, the platform supports the configuration of the following parameters:
Redis Storage Key Prefix
Internal Forwarding Parameter
Configuration Description
After configuring the cluster on the platform, log in to the decision-making platform as the admin and choose System Management > Intelligent O&M > Cluster Configuration. Then you can configure Redis Storage Key Prefix and Internal Forwarding Parameter on the parameter configuration page.
A tip icon will appear when you hover your mouse over the text box next to the configuration item during parameter configuration. You can click the icon to view the requirements for the configuration item.
Redis Storage Key Prefix
When the Redis server being used is a public service (namely also used by other projects), you need to customize the key prefix stored in Redis for each project to avoid key conflicts between multiple projects.
After the configuration and project restart, you can query the value of each new key prefix from Redis.
| Configuration Item | Default Configuration | Requirement | Prompt |
|---|---|---|---|
Key Prefix | __fine_redis_key__ | Uppercase and lowercase English letters, Arabic numerals, and underscores | Uppercase and lowercase English letters, Arabic numerals, and underscores are supported. Chinese and special characters are not supported. |
After you have modified the value of Key Prefix, click the Save button on the right. A prompt box pops up, displaying "The parameter settings have been modified. Restart each node project for the modification to take effect."
Internal Forwarding Parameter
Principle Description
Typically, a round-robin forwarding strategy is configured for the load balancer. The load balancer does not determine which node a particular request belongs to but forwards the request to each node according to the round-robin strategy. A node receiving a request that does not belong to it will internally forward the request to the appropriate node for processing. After processing is completed, the response is sent back along the original path.
Based on this logic, when an abnormal node cannot respond to an internally-forwarded request, the load balancer may incorrectly judge a healthy node as abnormal. This may cause the delay of the response to the request and the lack of error reporting on the frontend.
To prevent a single-node crash from causing the entire cluster to be unavailable, a health check for requests forwarded between nodes is added for FineReport to restrict abnormal nodes and trigger alerts on the frontend.
If a node server rejects the connection, the error message "Error Code: 41300002. The server rejects the connection." will be displayed.
If the forwarding time between cluster nodes exceeds the set timeout, the error message "Error Code: 41300001. The server response time is too long." will be displayed.
Configuration Description
| Configuration Item | Default Configuration | Unit | Requirement | Definition |
|---|---|---|---|---|
Timeout | 90 | Second(s) | Integer no less than 10 | Read/Write timeout period. If the server does not return or receive any data in the period, this situation will be regarded as a timeout. If calculation or export in some reports takes the backend several minutes or longer periods, you need to set a longer timeout period. This item corresponds to the parameters proxy_read_timeout and proxy_send_timeout in NGINX. The values of both the parameters should be greater than that of Timeout configured on the platform. |
Attempt Quantity | 8 | Times | Positive integer | Maximum number of attempts in a single cycle, which must be larger than or equal to 1. Maximum number of failed attempts (n), whose default value is 8. This item corresponds to the max_fails parameter in NGNIX. The value of this parameter is advised to be greater than or equal to that of Attempt Quantity configured on the platform. |
Expiration Time | 90 | Second(s) | Integer no less than 10 | Single expiration period in which a node is invalidated after the number of failed request attempts exceeds the upper limit. In this period, new requests will not be internally forwarded to the node. This item corresponds to the fail_timeout parameter in NGINX. The value of this parameter is advised to be greater than or equal to that of Expiration Time configured on the platform. |
After you have modified Internal Forwarding Parameter, click the Save button on the right. A prompt box pops up, displaying "The parameter settings have been modified. Restart each node project for the modification to take effect."
Configuration Validation
During parameter configuration, validation will be performed on both the frontend and backend. If the frontend validation fails, an alert will appear. If the backend validation fails, the data will not be written to the database.
Previous：WebLogic Server Folder Deployment
