bzp2010 opened a new pull request, #13904:
URL: https://github.com/apache/apisix/pull/13904
### Description
This PR aims to improve the reliability of configuration updates in
API-driven standalone mode by implementing the following measures:
- A new "standalone-status" reporting mechanism has been added. Now, each
subsystem on every worker will report the digest of its loaded configuration,
down to the level of each entity type (`worker:<id>:<subsystem>:<entity_type> =
<digest>`). This information will indicate whether the new configuration has
taken effect on each worker (e.g., the router tree will be reset; the consumer
lrucache will be flushed), and so on.
- The `PUT /apisix/admin/configs` request now supports a `wait` parameter.
It allows you to specify a value in milliseconds; APISIX will collect if
configuration applied status during this wait period and report it to the
client. It is based on the report on "standalone-status" mentioned above.
- This API now returns a `200` or `202`. A `200` status code indicates
that the configuration has been accepted and loaded on each worker, while a
`202` status code indicates that the configuration has been accepted but its
loading status is not guaranteed.
- Refactor the configuration loading from `shdict` to improve the
configuration loading latency window for new workers (which may be restarted
via `reload`). Configuration is now always loaded synchronously during
`init_worker` and consumed immediately during `core.config.new`.
### Checklist
- [x] I have explained the need for this PR and the problem it solves
- [x] I have explained the changes or the new features added to this PR
- [x] I have added tests corresponding to this change
- [ ] I have updated the documentation to reflect this change
- [x] I have verified that this change is backward compatible (If not,
please discuss on the [APISIX mailing
list](https://github.com/apache/apisix/tree/master#community) first)
<!--
Note
1. Mark the PR as draft until it's ready to be reviewed.
2. Always add/update tests for any changes unless you have a good reason.
3. Always update the documentation to reflect the changes made in the PR.
4. Make a new commit to resolve conversations instead of `push -f`.
5. To resolve merge conflicts, merge master instead of rebasing.
6. Use "request review" to notify the reviewer after making changes.
7. Only a reviewer can mark a conversation as resolved.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
