firlas
你是希望在 timer 里面使用 ngx.location.capture 么？
这个理论上也可以搞，不过可能相对改动大一些。
timer 里面选择使用 location.capture 而不使用 cosocket 是出于什么目的呢

还有其他希望在 timer 里面支持的么？

    imilli
    哈哈，有点多，也欢迎大家一起来贡献，齐头并进发展更快

        doujiang24 目前只遇到ngx.location.capture这个限制.

        原因是原本content_by_lua阶段的逻辑使用了很多capture, 因为考虑capture比完整请求要轻量.
        随着项目发展, 这些逻辑其中一些要跑在timer里了, timer不支持capture, 只好到处去ngx.get_phase()区分.

        看文档时我在想, 既然timer已经"will take one (fake) connection"了, 那不能干脆 take one (fake) request么, 然后timer逻辑发生在这个fake request的content_by阶段, 能使用content阶段所有功能.

        毕竟没看过源码, 很可能想的过于简单.

          feng
          这个 PR 只是完成 shdict 在 stream 和 http 之间共享呢
          完全的合并两个 lua vm，这是另外一个话题，其实合并也不太好

              firlas
              确实 timer 还不是完整的请求，没有 content phase 这个概念了呢，执行上也没有了呢
              要支持的话，还是有一些改动量的，当然也不是要引入 content phase 才可以，有其他路子

                  tweyseo 这个功能太有用.

                  如果考虑到nginx的设计, 请求到所有worker这个改动太大的话, 那一个可以广播自定义数据到所有worker的api怎样

                    tanjinhua 这个我已经用来代替kong的resty-event用在mlcache里了，算上编译过程，整个不算简单易用。要是OR本身可以支持，比如，直接配置listen 9527 BCST;，然后不管外部还是内部，只要是到这个端口的数据都是给所有worker都处理的，这样岂不是更好。

                      tweyseo 是的，系统本身自带肯定更好的，也是比较基本和使用的功能了；但是这个估计要修改 nginx 本身，工作量会比较大的。

                          6 days later
                          6 days later

                          jils2013
                          这个工程量也有一些，需要加入有 upstream zone 的概念，与此同时，搞了 keepalived_timeout 的支持，一直一起搞的也有 pool_size 的支持了

                              6 days later
                              5 days later

                              在实现oidc协议时，使用resty.http库只能指定IP，不能实现动态负载均衡，想使用ngx.location.capture发起子请求，重新走一次主流程 ，以动态负载的复用。发现ngx.location.capture不会执行主流程中的access_by_lua，从而不能实现动态选取后端节点，以及ngx.location.capture不支持自定义header 头，这样导致不能跟据header头中的host以及其它字段进行负载。