hanzhenfang commented on PR #13894:
URL: https://github.com/apache/apisix/pull/13894#issuecomment-6361516117

   I tested the shared-memory health fix with isolated APISIX 3.18.0 containers 
and a local HTTPS upstream. The core change addresses the ordinary priority 
picker under a controlled SHM-only state flip: without the patch, 24/24 
subsequent requests still selected the primary; with the core patch, 24/24 
selected fallbacks.
   
   I found two additional paths worth reviewing before considering the 
worker-divergence issue fully covered:
   
   1. `ai-proxy-multi` uses `checker.status_ver` for its own picker and 
health-status caches. With only the two core files from this PR mounted, a 
controlled SHM-only flip still sent 10/20 requests to the instance marked 
unhealthy in SHM. This agrees with the existing review comment about the AI 
picker.
   2. A request can arrive on a worker before its checker is created by the 
timer. In an initial run with the AI cache-key change but without a direct SHM 
lookup for the nil-checker path, 7/20 requests still selected that unhealthy 
instance during checker creation.
   
   Draft 3.18 backport #14072 contains candidate code and Test::Nginx cases for 
the AI caches and nil-checker window. With those additions, the controlled 
late-checker experiment sent 40/40 ordinary requests to fallbacks and 40/40 AI 
requests to the healthy instance. The natural, intermittent Kubernetes 
event-loss scenario was **not** reproduced locally. The new `.t` files have 
**not** passed Test::Nginx locally because that dependency is missing in this 
environment; the Docker request/response runs and logs are the current executed 
evidence.
   
   Would you prefer these additions in #13894, or as a separate follow-up 
against `master`? I can prepare a master-based delta rather than retargeting 
the 3.18 backport.
   


-- 
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]

Reply via email to