bzp2010 commented on code in PR #12604:
URL: https://github.com/apache/apisix/pull/12604#discussion_r2343921386
##########
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:
> if config[METADATA_LAST_MODIFIED] > last_sync_time then
This introduces two distinct time coordinate systems and compares them.
Although both are epoch timestamps, their starting points may be unreliable.
For example, NTP might occasionally cause system time to roll back.
Each instance may have multiple workers, any of which could restart at any
time. I believe this creates the potential for time inconsistencies across
workers, which we can entirely avoid.
What I mean is that we should ideally use a single time coordinate system
and avoid numerical comparisons whenever possible. That is, if we all use
LAST_MODIFIED, I can simply perform equality checks. Timestamps should only
ever be written by a single worker; other workers should not generate another
timestamp for comparison. This is likely a more robust design.
---
I don't understand how `last_sync_time` affects the timer. Shouldn't we be
able to simply register a fixed timer using `ngx.timer.every`?
Regarding the overhead of `shdict:get`, this is primarily memory-related,
with the overhead occurring in the locking portion. If you believe these
timer-driven `get` operations might also incur unexpected overhead due to lock
waits, I think we could introduce some random delays before `shdict:get`. This
would spread out the `get` calls as much as possible, striving to avoid the
lock being held at that exact moment.
Regarding the overhead of JSON decode, if this is a concern, we can change
the encoding method for shdict to use text encoding like
`<LAST_MODIFIED>|<DIGEST>|<JSON>`. This way, data extraction can be done using
PCRE, which can be JIT optimized.
--
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
