Resolved Issues in Earlier Versions of Spring Cloud Huawei and Java Chassis
This section lists all the issues that have been resolved in earlier versions of Spring Cloud Huawei and Java chassis.
Spring Cloud Huawei
Spring Cloud Huawei Version |
Resolved Issues |
1.11.6-2023.0.x |
|
1.11.6-2022.0.x |
|
1.11.6-2021.0.x |
|
1.11.4-2022.0.x |
|
1.11.4-2021.0.x |
|
1.11.3-2022.0.x |
When a service name was specified, the instance isolation policy did not take effect. |
1.11.3-2021.0.x |
|
1.11.2-2022.0.x |
|
1.11.2-2021.0.x |
|
1.11.0-2022.0.x |
The trace context configuration did not take effect based on dynamic configuration. |
1.11.0-2021.0.x |
|
1.10.13-2021.0.x |
When multiple services were called at the same time, the degradation did not take effect. |
1.10.11-2021.0.x |
Instance isolation governance did not take effect. |
1.10.9-2021.0.x |
|
1.10.8-2021.0.x |
The load balancing rule did not take effect. |
1.10.8-2020.0.x |
|
1.10.7-2021.0.x |
When service registry and discovery was disabled, the start failed. |
1.10.7-2020.0.x |
|
1.10.6-2021.0.x |
Environment information was missing from the monitoring information. |
1.10.6-2020.0.x |
|
1.10.5-2021.0.x |
There were too many retries. As a result, the request was not responded for a long time. |
1.10.5-2020.0.x |
|
1.10.4-2021.0.x |
The identifierRateLimiting context failed to be obtained. |
1.10.4-2020.0.x |
|
1.10.3-2021.0.x |
The governance configuration did not take effect when it was changed for the first time. |
1.10.3-2020.0.x |
|
1.10.2-2021.0.x |
|
1.10.2-2020.0.x |
|
1.10.1-2021.0.x |
|
1.10.1-2020.0.x |
|
1.10.0-2021.0.x |
|
1.10.0-2020.0.x |
|
1.9.1-2020.0.x |
|
1.9.0-2020.0.x |
When instance.healthCheck.mode was pull, the custom healthCheckInterval did not take effect. |
1.8.0-2020.0.x |
|
1.7.0-2020.0.x |
|
1.6.1-2020.0.x |
NOTE:
Major problems exist. You are not advised to use it:
|
1.9.4-Hoxton |
When a configuration update event was released in the same configuration center configurations, the pooling configuration may not be found during the request. |
1.9.3-Hoxton |
When a service was deleted or restarted, the Ribbon cache cannot be updated. As a result, the request was sent to an unavailable service. |
1.9.2-Hoxton |
After an instance was deleted and another instance was registered on the server, the client selected an incorrect server instance. |
1.9.1-Hoxton |
|
1.9.0-Hoxton |
When instance.healthCheck.mode was pull, the custom healthCheckInterval did not take effect. |
1.8.0-Hoxton |
|
1.7.0-Hoxton |
|
1.6.0-Hoxton |
|
1.5.9-Hoxton |
|
1.5.8-Hoxton |
|
1.5.6-Hoxton |
|
1.5.0-Hoxton |
|
1.6.4-Greenwich |
When a configuration update event was released in the same configuration center configurations, the pooling configuration may not be found during the request. |
1.6.3-Greenwich |
When a service was deleted or restarted, the Ribbon cache cannot be updated. As a result, the request was sent to an unavailable service. |
1.6.1-Greenwich |
An exception occurred during cross-application service discovery of the gateway. |
1.6.0-Greenwich |
|
1.5.0-Greenwich |
|
v1.3.3-Greenwich |
The listening function of the registry center did not take effect. |
1.6.1-Finchley |
|
1.6.0-Finchley |
|
1.5.1-Finchley |
Governance configurations in the configuration center can still be used after being deleted. |
v1.3.9 |
NOTE:
Major problems exist. You are not advised to use it: A critical service forwarding error occurred in governance. |
v1.3.8 |
NOTE:
Major problems exist. You are not advised to use it: A critical service forwarding error occurred in governance. |
v1.3.4 |
|
v1.3.3 |
|
v1.3.2 |
|
v1.2.0 |
When the default AK/SK configuration was read from ServiceStage, too many objects were initialized, causing memory leakage. |
v1.1.0 |
|
v1.0.0 |
Automatic service discovery cannot be performed in some scenarios. |
v0.0.3 |
|
Java Chassis
Java Chassis Version |
Resolved Issues |
3.1.0 |
|
3.0.2 |
|
3.0.1 |
Fallback label-based routing was supported. |
2.8.16 |
idleTimeout was incorrectly set. As a result, some connections were closed. |
2.8.15 |
When multiple identical keys existed in the configuration center, the updated configuration did not take effect. |
2.8.14 |
|
2.8.13 |
|
2.8.12 |
|
2.8.11 |
When DefaultHttpClientFilter failed to deserialize the response body, the exception information was incorrect. |
2.8.10 |
|
2.8.9 |
|
2.8.8 |
|
2.8.7 |
The available AZ was null by default. |
2.8.6 |
|
2.8.5 |
If the number of consecutive errors was 0 or fewer, the error percentage cannot take effect. |
2.8.4 |
The request was incorrect because the instance change time was abnormal. |
2.8.3 |
The definition of caseInsensitive in the routing rule was modified. |
2.8.2 |
|
2.8.1 |
The load isolation switch did not take effect. |
2.8.0 |
|
2.7.10 |
|
2.7.9 |
A null pointer exception occurred when autoDiscovery was enabled. |
2.7.8 |
|
2.7.6 |
|
2.7.5 |
|
2.7.3 |
|
2.7.0 |
IsolationDiscoveryFilter created too many objects. |
2.6.3 |
|
2.6.0 |
|
2.5.2 |
The default value of idleTimeout for the ServiceComb client connection was changed from 60s to 30s. |
2.5.1 |
An exception was thrown when the kie pulled an empty configuration for the first time. |
2.5.0 |
RPC failed to be called in the vert.x work pool. |
2.3.0 |
|
2.2.4 |
|
2.2.3 |
|
2.2.2 |
|
2.2.1 |
|
2.2.0 |
|
2.1.6 |
|
2.1.5 |
|
2.1.3 |
|
2.1.2 |
|
2.1.1 |
|
2.1.0 |
|
2.0.2 |
|
2.0.1 |
|
1.3.11 |
|
1.3.10 |
|
1.3.9 |
A null pointer exception occurred on the rate limiting governance rule. |
1.3.8 |
The instance isolation filter did not take effect. |
1.3.7 |
IsolationDiscoveryFilter created too many objects. |
1.3.5 |
|
1.3.3 |
|
1.3.2 |
|
1.3.1 |
|
1.3.0 |
|
1.2.0 |
|
1.1.0 |
|
1.0.0 |
|
|
|
0.5.0 |
|
0.4.0 |
|
0.2.0 |
|
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot