alexzzh

> 这似乎是源码上讨论的问题， > > > [内存泄漏,fail时需调用ngx_slab_free_locked(shpool, peer_shm[index].sockaddr)](https://github.com/alibaba/tengine/blob/master/modules/ngx_http_upstream_check_module/ngx_http_upstream_check_module.c#L1249) > > 这个逻辑是 > > 1. 共享内存加锁 > 2. 操作共享内存 > 3. 如果步骤2异常需要退出（引用代码处），则把共享内存锁摘除，防止其他进程 运行此逻辑锁死。 > > 所以这里不确定你遇到什么问题。这个逻辑如果不解锁反而异常 https://github.com/alibaba/tengine/blob/master/modules/ngx_http_upstream_check_module/ngx_http_upstream_check_module.c#L1239 这里如果goto fail, 最好判断 ``` if...

> > * [访问共享内存时数据时没有加锁保护 1](https://github.com/alibaba/tengine/blob/master/modules/ngx_http_upstream_check_module/ngx_http_upstream_check_module.c#L1514) > > * [访问共享内存时数据时没有加锁保护 2](https://github.com/alibaba/tengine/blob/master/modules/ngx_http_upstream_check_module/ngx_http_upstream_check_module.c#L1484) > > * [共享内存锁(shpool->mutex)和节点锁存在使用混乱 1](https://github.com/alibaba/tengine/blob/master/modules/ngx_http_upstream_check_module/ngx_http_upstream_check_module.c#L1370) > > * [共享内存锁(shpool->mutex)和节点锁存在使用混乱 2](https://github.com/alibaba/tengine/blob/master/modules/ngx_http_upstream_check_module/ngx_http_upstream_check_module.c#L1187) > > 这里严谨的需要全部加锁。但是因为估计当初逻辑是再通用硬件上操作，默认原子操作cmp和inc。这里标记TODO估计也有考虑这个。 是的，但是这里ref、owner 类型并不是ngx_atomic_t类型的，代码上多处有访问共享内存不加锁的情况

code should be motified, see below: ``` diff --git a/src/ngx_http_vhost_traffic_status_control.c b/src/ngx_http_vhost_traffic_status_control.c index 7b7222f..66da8f1 100644 --- a/src/ngx_http_vhost_traffic_status_control.c +++ b/src/ngx_http_vhost_traffic_status_control.c @@ -44,7 +44,7 @@ ngx_http_vhost_traffic_status_node_upstream_lookup( { ngx_int_t rc; ngx_str_t key, usg, ush;...

> “需要同时在higress-gateway中的PORTS中添加对应端口”，这个是指修改 higress-gateway 的 K8s Service 吗？ 对 不好意识，问题没描述清楚。

> 变更冻结这种需求是否应该在源头进行限制，而不是在最终生效的地方？ > > 你上面也提到了，不管是谁重启，controller 还是 gateway，都会导致被冻结的变更在终端生效，产生预期外的配置变更。 用户现场，我们总是会遇到有人(不一定是自己人)操作后台，并因此受到处罚，所以依赖"口头约定“是最不可靠的。 源头限制是一个比较好的方案，整个控制面(包括ui)都是"只能查，不能改"状态，但这涉及的面可能更广。

> > > 变更冻结这种需求是否应该在源头进行限制，而不是在最终生效的地方？ > > > 你上面也提到了，不管是谁重启，controller 还是 gateway，都会导致被冻结的变更在终端生效，产生预期外的配置变更。 > > > > > > 用户现场，我们总是会遇到有人(不一定是自己人)操作后台，并因此受到处罚，所以依赖"口头约定“是最不可靠的。 源头限制是一个比较好的方案，整个控制面(包括ui)都是"只能查，不能改"状态，但这涉及的面可能更广。 > > 建议是从变更源头来限制。比如大家一般修改配置都是走UI，那么UI卡住可以满足绝大部分的需求，而且变更风险低。 是的 ， 如果能ui强制限制配置调整肯定更好，这个需求是我们的业务需要。 目前的修改是提供开关，默认不影响程序原来的行为。 我这边改不了前端代码. ^V^

> > > > > 变更冻结这种需求是否应该在源头进行限制，而不是在最终生效的地方？ > > > > > 你上面也提到了，不管是谁重启，controller 还是 gateway，都会导致被冻结的变更在终端生效，产生预期外的配置变更。 > > > > > > > > > > > > 用户现场，我们总是会遇到有人(不一定是自己人)操作后台，并因此受到处罚，所以依赖"口头约定“是最不可靠的。 源头限制是一个比较好的方案，整个控制面(包括ui)都是"只能查，不能改"状态，但这涉及的面可能更广。 > >...

> > > > > > > 变更冻结这种需求是否应该在源头进行限制，而不是在最终生效的地方？ > > > > > > > 你上面也提到了，不管是谁重启，controller 还是 gateway，都会导致被冻结的变更在终端生效，产生预期外的配置变更。 > > > > > > > > > > > >...

> 我不建议通过debug接口控制单个实例的配置，可以尝试的做法是在全局配置里增加一个开关来进行控制。 这里的全局配置指的是使用 higress-config 这个configmap 吗? 一开始考虑过这个方案。 因为希望调整这个开关时不需要重启就能生效，所以不能作为deployment中的环境变量, 使用higress-config 这个configmap是一个方案，但存在一些弊端: 1 目前 higress-config 这个configmap 中属于higress的每个全局变量都会生成对应的envoyfilter， 如果在这里增加一个控制开关，会打破“全局配置都会生成envoyfilter”这个约定，当然这个约定可能本身就不存在，也不应该存在，对于用户来说，只要配置能动态生效，不会关心具体实现，只是现在higress的全局配置比较少，看起来存在这个约定而已 ==》这不是关键原因 2 考虑到service 、config、eds update、global config变更时最终都会调用 ConfigUpdate， 将来还会有其他场景调用该函数，所以控制点选择在 ConfigUpdate接口内部，比较收敛，向前兼容 ---- 基于这个考虑，目前的实现是在 `DiscoveryServer` 中增加开关变量以及在`ConfigUpdate` 函数中判断这个变量值，...

> @alexzzh 感谢你详细的说明，我理解你的顾虑，第一点确实不是关键问题，第二点侵入性的问题，可以看下更合适的修改方式。 不考虑在debug接口支持这个功能是因为会增加运维成本，需要逐个控制面进行操作配置，可能你们的场景比较特殊控制面只有一个节点，但很多用户都是多节点部署控制面的。 好的， 如果是多控制平面确实不方便，这点没考虑到。