bzp2010 commented on code in PR #12604:
URL: https://github.com/apache/apisix/pull/12604#discussion_r2336329176
##########
apisix/admin/standalone.lua:
##########
@@ -420,6 +430,29 @@ function _M.init_worker()
end
events:register(update_config, EVENT_UPDATE, EVENT_UPDATE)
+ -- due to the event module can not broadcast events between http and
stream subsystems,
+ -- we need to poll the shared dict to keep the config in sync
+ local last_sync_time = ngx_time()
+ local function sync_config()
+ local now = ngx_time()
+ if now - last_sync_time < 1 then
+ return
+ end
+
+ local config, err = get_config()
+ if not config then
+ if err ~= NOT_FOUND_ERR then
+ core.log.error("failed to get config: ", err)
+ end
+ else
+ if config[METADATA_LAST_MODIFIED] > last_sync_time then
+ update_config(config)
+ end
+ end
+ last_sync_time = now
Review Comment:
Event-triggered updates should also update the last sync time on each
worker, so the last sync should be a file-level variable rather than in
init_worker.
Each timer loop only needs to check whether the last modification stored in
shdict is consistent with the modification time of the current worker to
determine whether the timer needs to update again.
Since the worker is single-threaded, we don't need to worry about races. If
an update is already triggered by an event, the timer loop will never intervene
and repeated updates will not occur. Since UDS communication is almost always
faster than our fixed-interval timer, most updates will be triggered and
executed by events.
Only in rare cases, such as when a new update occurs immediately after the
UDS event broadcast and the worker has not had time to receive it, will the
timer detect the difference between the last sync time and shdict and perform
an update. This is expected to be rare, and even if it happens, our design is
sufficient to handle it correctly.
Therefore, we can assume that in most normal cases event broadcasting will
take effect, and the last sync time on the worker will always be overwritten by
the update triggered by the event and consistent with the shdict, so the timer
loop will not actually work.
This timer only works when event broadcasting is abnormal or when
broadcasting to stream from http side. In this case, since the last sync time
is not overwritten by the event triggered update, the timer loop will actually
update the configuration. In most cases, it is just a fallback.
--
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: notifications-unsubscr...@apisix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
